Letter from the Team

What is software for?

In today’s society, software seems to have become bloatware in a suit and tie that can waltz into any organization and charge obscene amounts of money to accomplish obscenely little. Claiming to provide business critical functions and do things the user otherwise couldn’t accomplish, or in half the time.

But this isn’t a new problem, is it? In a 1980s episode of Computer Chronicles, there was a demo of spreadsheets (Excel) by Microsoft. And the consensus in the room was that spreadsheets were software so powerful, it was useless.

Between the 1950s and 1970s, software had to be written with special care and attention to resource consumption. You couldn’t just write code willy nilly. You had to think about how much memory a given function or loop used. And because that mattered, you had to make sure, from the very beginning, that every function and loop had a non redundant purpose that served the end goal of the software. No dead code. No wasted loops. No pointless strings. No inefficient algorithms.

But how did you know if a given operation was efficient or even necessary? You were forced to sit with the purpose of the software itself, which almost always came down to one of three things: entertaining the human operator, making them more efficient at a task, or handing them critical information they needed and didn’t otherwise have.

Which meant you had to actually understand the user. How they think. How they’d normally get the task done without your software. What your software was replacing in their day. Those questions gave developers the data they needed to write lean, efficient code that made the human operator genuinely more capable, or, in the case of Pong, genuinely more entertained.

Notice what that constraint actually was. Memory scarcity forced every function to justify itself against one undivided standard: did it serve the person on the other end of the terminal. There was no slack in the system to waste on a feature that existed for any other reason. The technical limit and the human purpose weren’t two separate concerns a good engineer happened to balance. They were the same concern, looked at from two ends of the same wire.

Francis Schaeffer, writing about the fracture of Western thought long before anyone was worried about software, described modern man as having split his world into an upper story of meaning and value and a lower story of fact and mechanism, with the two no longer speaking the same language. I think that’s exactly the disease that’s overtaken this industry.

Every product still speaks fluently in the upper story. Empowerment. Efficiency. Insight. Transformation, or whatever buzzword is in season. Every pitch deck and landing page promises the same augmentation Engelbart promised when he built the mouse and the modern interface around one load bearing goal: the “augmentation of human intellect.”

But the lower story, the actual mechanism by which the product gets built, funded, and shipped, walked away from that goal a long time ago. It answers to retention and attrition curves now, to seat expansion, to a board that wants the roadmap full regardless of whether anything on it makes a single person’s day easier. The words stayed upstairs. The machine went to work downstairs on a completely different job. Nobody told the user the two had stopped talking to each other, so the user, not unreasonably, still takes the upper story at its word. We see the gap between those two floors every single day.

The philosopher Jacques Ellul had a name for what happens once a mechanism like that slips its original purpose. He called it “autonomous technique”: a process that starts out serving a human end and ends up optimizing for its own internal measure of efficiency, indifferent to whether that optimization helps anyone at all. A feature ships not because a user asked for it or because it removes friction from something real, but because it’s measurable, because it’s a line item on a competitor’s comparison chart, because building it is easier than asking whether it should exist. The software isn’t exactly lying to you. It just stopped caring about the question that used to govern every line of code, the question a systems programmer in 1965 couldn’t dodge because the hardware itself wouldn’t let him: does this justify its cost to the person who has to use it?

And we’ve drifted a long way from that. Something like 90 percent of software today doesn’t exist to make the user more efficient. It exists to compete with some other product for market share. Design got shoved to the back seat to make room for the dollar. Companies that were founded and run by practitioners and engineers got handed off to MBAs and Wharton grads whose real goal was never the end user’s life getting better. It was margin, a cloned idea, and an exit, so they could go build the next money making thing.

Neil Postman, while talking about a culture that had accepted technical efficiency as its only legitimate measure of value, warned that such a culture eventually loses the vocabulary to even ask whether a technology made anyone better off, because “better off” stops being a question its instruments know how to register. That sounds like a pretty accurate description of a quarterly board meeting where engagement is up, churn is down, and not one person in the room has asked whether the product now takes the customer’s staff longer to run than the spreadsheet it replaced, or whether anyone on the team could actually name the customer’s real pain point.

Venture capital deserves some of the blame here, for mistaking buzzword soup for real innovation. But so do the organizations that quietly stopped caring about picking the right tool for the job and just making their people’s lives easier. Every org has decision fatigue, sure, but a lot of that fatigue comes from middle and upper management who’ve rarely sat close enough to the actual work to know what “effective” even looks like for a given tool. They inherited the upper story vocabulary without ever standing downstairs at the terminal, where the old discipline used to live. So they have no way of noticing when a vendor’s promise of augmentation quietly turns out, on delivery, to be just one more thing their team has to learn.

That’s the whole problem in one sentence: the roadmap answers to metrics that say nothing about whether the user’s total burden went up or down. You can’t derive a promise of empowerment from a lower story built entirely out of retention math, the same way you could once derive Engelbart’s promise straight from his actual mechanism. The user is asked, in effect, to take it on faith that the software will make them more capable, because nothing about how the software actually gets built is answerable to that claim anymore.

The founding principle of Thalorin was simply this: software should fit your process, not the other way around. We didn’t build it because GRC is a lucrative, sticky market, though it certainly is. We built it because the compliance space is drowning in tooling that calls itself GRC while making the job slower, not faster, and that’s not just an efficiency problem. It’s a national security problem, because every hour a security engineer loses fighting their own tools is an hour not spent finding the thing that actually gets a company breached. We watched teams spend two million dollars a year on GRC tooling that sat dormant, because a spreadsheet was still faster than the platform they’d paid for.

Until they found Thalorin.