The Human Condition of Software

Software Amnesia

There is a particular kind of professional amnesia reserved for industries that experience a sudden drop in the cost of their primary activity, and the software industry is currently living through a spectacular case of it.

For about forty years, software was expensive — not just in dollars, in thought. You planned before you typed because typing cost you a week. You specified before you built because rebuilding ended careers. The expense was doing useful philosophical work in the background - it made people think. Thinking, in most professions, is not something you do because you enjoy it. Thinking is something you do because the alternative is ruinous.

First gradually and then suddenly, software got cheap. Frameworks, then cloud, then AI. A prototype that would have taken six weeks in 2014 takes an afternoon in 2026. This is nothing short of a miracle. It is also a quiet catastrophe for the discipline of thinking before building. Software has, at some point in the last decade, stopped regarding thinking as essential.

Other professions escape this fate because their medium pushes back. For a lawyer, the law does not change mid-brief. For a Civil Engineer, physics does not revise itself because the client saw a LinkedIn post. A foundation, once poured, does not accept feedback. An Architect does not swap out a cantilever bridge halfway for a suspension bridge because Elon Musk tweeted about it. The medium enforces the thinking the professional might otherwise be tempted to skip.

The concrete has already set. The software has not, will not, and by design cannot, which is exactly the condition that requires the discipline that nobody has time for.

𝖱̶𝖾̶𝗊̶𝗎̶𝗂̶𝗋̶𝖾̶𝗆̶𝖾̶𝗇̶𝗍̶𝗌̶ Vibes with a Deadline

I don't know exactly when it started, but somewhere in the last few years, requirements quietly became vibes with a deadline.

I want something like ChatGPT for our finance team.

Can we have a dashboard that shows, you know, the important stuff?

Build me something the client will like.

These are not requirements. These are wishes articulated in the presence of a budget. But they survive and multiply, because the cost of mistaking them for requirements has collapsed. When code was expensive, a fuzzy requirement had a visible price tag — weeks of wasted effort, whiteboards full of recrimination, a general sense among all parties that something had gone wrong. Now a prototype exists in two hours, and the illusion completes itself:

That building is the same as thinking.

It is not. Yes, we can produce a working prototype of entirely the wrong thing before lunch, but we have still produced the wrong thing, merely with impressive speed and a pleasing syntax-highlighted finish. I say "we" deliberately when I describe this. I too once shipped apps that solved a problem nobody actually had, beautifully, on time, with full test coverage, and a design review where everyone said it looked great. It was great. It was also useless, which I discovered after launch when the usage logs told me what I should have asked the requestor in week one. I have nodded along to "we'll figure it out in iterations" in meetings where I should have suggested we figure it out in this meeting, before anyone opens an IDE (or Cursor, if you're Gen Z).

Speed won't fail us, lack of thinking will.

The Agile Trap

The software industry has always found itself in a curious corner and it goes like this: you spend two years building something, deliver it on a Tuesday, and by Wednesday morning discover that nobody wants it anymore, possibly including the person who asked for it.

This happened enough times in the 1980s and 90s that the industry, which is nothing if not inventive when cornered, decided to formalize this confusion into a methodology. They called it Agile. The idea was simple: if we are going to be wrong, let us at least be wrong in smaller, more frequent, and more recoverable ways. Instead of being catastrophically wrong once every two years, we would be modestly wrong every two weeks. This was considered progress, and in fairness, it was.

Software exists in a realm where the cost of changing one's mind is theoretically low, the medium resists prediction, and the builder is expected to be clairvoyant about what the requestor will want six months from now. Agile is the industry's collective admission that clairvoyance is not, in fact, a marketable skill.

Agile was designed to manage one specific kind of uncertainty — feature uncertainty. What should the button do? Where should the dashboard live? What do users actually click? These are bounded, genuinely iterative questions, and Agile answers them beautifully. What Agile was emphatically not designed to manage is structural uncertainty. Whether you need a database at all. Whether this is one system or three. Whether the thing being requested is a product, a feature, or a philosophical misunderstanding of what the company does.

Agile is for deciding the colour of the paint, not for deciding if we should have walls

Agile is not the villain of this story. Agile is, at most, an accomplice who happened to be in the room when the crime was committed. The reason Agile works — where it works — is that software has a property almost nothing else does. Software is invisible until it runs, malleable to the point of insult, and only reveals its true requirements once you can actually see it working. You don't know what you want until you see what you didn't want.

Somewhere between the Agile Manifesto and the invention of the standing desk, the two categories of uncertainty quietly merged into a single bucket labelled "we'll figure it out in iterations." This bucket now holds, in no particular order: missing requirements, unasked stakeholder questions, architectural decisions no one wanted to make, competitive panic, executive whims, and the occasional half-formed thought someone had in the shower.

This is not Agility. This is maximum Fragility masquerading as Optionality

MVP Is Never the Product

Experimentation is how you find out whether the thing you want to build is something the market actually wants — which is, when you think about it, a question worth answering before you spend months building it. MVPs are good. POCs are good. The disposable, scrappy, learn-fast probe is a brilliant invention. The problem is not experimentation. The problem is that we have quietly stopped distinguishing between the experiment and the product, and they are not the same thing.

An MVP is a market instrument. Its job is to answer one question: does anyone want this? It is built fast, built rough, built to be wrong. Its data model is throwaway. Its architecture is held together with optimism and duct tape.

The product is something else entirely. The product is what you build after the MVP comes back with an answer. Different scale assumptions, different failure modes, different bones. It is structurally a different object from the MVP — even when they look identical from the outside. They share a problem statement and possibly a logo. That is roughly where the resemblance ends.

It does not do to dwell on dreams and forget to live - Albus Dumbledore, Harry Potter & The Philosopher's Stone

The real problem happens when the MVP shows us exactly what we wanted to see. The moment an MVP shows the slightest hint of traction, somebody asks when we can ship it. Not when can we build the real thing. When can we ship this. And nobody says the sentence that needs saying: what we just demoed was a probe. The market said yes. Now we throw this away and build the actual product.

Instead we keep iterating on the probe. We bolt auth onto code that was written to be deleted. We graft a real database onto a data model sketched on a napkin. We wrap monitoring around a system whose version control exists in Slack. This is not iteration, this is accumulated denial.

Organizational Fragility

The truly unfortunate thing about services companies — and here one must speak gently, because the people involved are doing their best, and I am one of them — is that we have been convinced our moat is keeping up. Our actual moat is the ability to fill the gaps between other companies' moats. We are the connective tissue of the enterprise world. The integration layer. The translation service between one company's ambition and another company's API documentation. This is genuinely a valuable thing to be. It is also a thing that produces a kind of existential twitch which is transmitted downward as urgency.

I skate to where the puck is going, not where it has been. - Wayne Gretzky

If you run to where the puck currently is, you will reach a rectangle of ice where the puck used to be. If you run to where the puck currently is faster, you will reach that same rectangle sooner, which is not the improvement it sounds like. The only people who reach the puck are the ones who anticipated where it was going — and anticipation requires, of all things, stillness.

Nietzsche would call this the servile pursuit of the market. A company which chases every trend has not chosen its values — it has allowed a thousand strangers on the internet to choose them for it. If you choose your mountain and start climbing it, you might end up somewhere. If you keep switching the mountains, you'll end up in the valley.

I said this during the #AISummit earlier this year, and it is still the most concentrated thing I know how to say about all of this. The companies finding success in the AI world are the ones exceptionally aware of who they are, what they want to build, and who they want to build it for.

AI isn't the strategy. Integration isn't the strategy. Those are enablers. Clarity is the strategy.

The companies that matter in five years will not be the ones that chased the puck fastest. They will be the ones that had the philosophical spine to say this is our game, these are our values, this is the edge we are willing to bleed for — and everything else is noise we will not dignify with a sprint.

You cannot out-react the market. You can only out-choose it.

The time given to us is finite. The trends are not. What to do with that asymmetry is, in the end, the only question that matters.