Software Is Like Prose
Sustained coherence is rare.
What makes a story good?
At the lowest level, the author has to be literate. At the highest level, a point needs to be made.
But the correctness of these layers is mostly irrelevant. The work of writing and the weight of the result is in between using words, to build structure, to make an interesting point.
Take the classic Crime and Punishment. It’s is a story about the morality of murder, where a man kills an innocent victim and is punished by his conscience. Is that one-liner summary as impactful as the book itself? Of course not. Are the differences between the Russian original and the English translations the main provocation of the text? Of course not.
Crime and Punishment makes you believe that murder is intrinsically wrong, despite the law. It shows you the sweat on Raskolnikov’s face. The paranoia of seeing people in the street, afterwards. The dread he can’t talk himself out of. He can’t even drink a cup of tea, without laying down for a few hours. All the little things add up to make the point.
In prose, paragraphs and their order obviously matter more than any one word or summary. Good writing is an irreducible set of novel connections between proper nouns. Raskolnikov beat an old woman to death with an axe and then stole her jewels. Here’s why and how he was haunted by his actions and the slim chance he might find relief. Good writing is an effective package for a big idea.
But big ideas are fragile while they’re young.. They have to be held in high resolution, in at least one mind, until they’re sturdy enough to live on their own. A single misplaced scene in Crime and Punishment might make the whole thing goofy or fantastic, and so the author has to consider everything, all at once. Coherence like that is difficult in a single mind, and even harder across many. The book could not of been written without a single editorial spine.
In prose, we know this much in our bones. In software, it is also true, but confused by the necessity of collaboration.
But Steinbeck said there aren't any good collaborations. I think he’s exaggerating. The Beatles existed, right? Organizations do stuff and are priced appropriately. The reason behind Steinbeck’s rhetoric is that incomplete ideas tend to spoil in transit. And original ideas can't be bootstrapped from training, because there’s not much to look at prior.
Don't focus too much on the words.
What makes a database good (viz. appropriate)? Many things. What makes a spreadsheet good? Many things, including a good database. When discussing a spreadsheet, if we overwhelmingly discuss the database over the data in it, we're lost.
Imagine insisting Dune should take place in an ocean instead of a desert. Or that Raskolnikov should’ve lived in a house instead of an apartment. Ok, maybe, but that's not really the point, now is it?
A green engineer gains a stripe after convincing the team not to do something. To stay focused on what matters, instead of stressing about (relative) trivialities. For ex., after quelling their first obstinate contrarian, the type who seems to argue for sport. Or the feature creeper, premature optimizer, framework evangelist, functional purist, collector of micro services, etc.
The only question that counts is the final one. Can you build something that’s useful? Everything else is subordinate.
I haven’t yet seen Claude outright suggest switching from PostgreSQL to Mongo or from C++ to Rust. When it does do such work, it’s usually because someone directly prompted it to. And so these kinds of decisions will become less a function of politics and even more one of contentiousness.
With or without AI, you need to eventually graduate past the elementary. The real work is in the details.
All finished software is alike. All unfinished software is unfinished in its own way.
Ignorance of a project’s specifics is insidious. Pattern matchers gotta’ pattern match. We look at a new piece of complexity and think of how it’s similar to something we’ve already seen. “Oh, at my last job, we used…” But familiarity is a bad priority, and analogies are only useful lies.
Example:
You want to build a fast spreadsheet for massive financial data. You’ve sketched out the particulars and have picked an appropriate (enough) stack. So, you are literate and have a thesis.
You begin.
Months later, you have a unique insight into your special solution. You are wise in new territory.
Questions you’ve asked and answered:
Accounting data for that fortune 100 retail company is voluminous and highly dimensional. But that SaaS startup’s whole balance sheet fits in L3 cache. How do we accommodate everyone?
QuickBooks data tends to be inconsistent between syncs, and it’s offered in different resolutions depending on the intermediary vendor. How do we work with that?
People tend to want high level aggregations to update immediately, but are tolerant of pipelined updates at finer levels of precision. How do we balance the load?
…
This list is too simple, but already tedious as an example. That’s part of the point.
Lists like these exist in every complex software project. They’re only alike insofar as each complex project is complex. This list is basic enough to make a pithy point, but minimally so; everyone knows what a spreadsheet is. What exists in the wild is even more alien and heterogeneous.
Imagine the equivalent in The Lord of the Rings:
Hobbits, wizards, and elves all live in the same world but operate under different traditions, developed from different histories. How are those histories internally consistent?
Why must the Ring be destroyed in Mount Doom, rather than elsewhere? How do such constraints help to make the point?
Aragorn is a man, and men are flawed. How is it possible for him to transcend his limitations? Why are the same flaws tragic in Boromir?
Why are orcs unforgivable?
…
Could The Lord of the Rings have been just as well written by a dozen people, all working from a shared Product Requirements Document? Is Stephen King uniquely qualified to finish a few chapters because of his similar accomplishments?
A catch-22: experienced newcomers can only have experience that approaches relevance to a complex problem (i.e. one with a unique solution). Inevitably the newcomer ships a bug, the result of missing a piece of knowledge already hard won by the tenured staff. Eventually the newcomer becomes a veteran, and the process repeats. We call it the cost of doing business. No one minds… except the user.
Legible abstractions and portable code are lofty aspirations, done better by some than others and to varied effect. But uniquely irreducible complexity is inevitable.
Boundaries between abstractions are not just defined by clean APIs, but by the effective and long-term ownership of complexity. In the real world, there is no such thing as an agnostic client or a generic implementation.
And so, you shouldn’t knock down Chesterton’s Fence until you learn why it was erected. But it’s better to never forget why it was built in the first place. Ideally, because you were the one that built it.
Large organizations contain multitudes.
A large software organization is a composite of contradictory goals. It works well enough. Your phone turns on, the emails arrive, this page loads.
Cue all the standard coordination-problem and management-theory literature:
Incentives matter
Goodhart’s law
Scarring on the first cut
The Clock of The Long Now.
All of it is in service to maintaining coherence among contributors, a few of which are expected to be authors by the law of large numbers (of staff). But with time, bureaucratic brain-plaque tends to accumulate. Higher order sclerosis. A law of old age (for now).
Some successful organizations point to Culture as part of the reason for their success, but with a mystical reverence. Culture is often treated as a cause; more often it’s the residue of success.
Under all the speculation on what makes the engine run, the need for ownership is bedrock.
Longevity should be a more common characteristic in promotion rubrics. If someone spends years managing the complexity of a problem, we should aim to retain their wisdom and reward them for continuing to offer it (assuming there’s still work left to do). Encourage successful books, not single chapters.
The story of PayPal and Max Levchin’s “Maxcode” comes to mind. Maxcode was the (apparently too) clever C++ that Max wrote PayPal’s early implementation in. A lot of template metaprogramming and the like. It was notoriously difficult to understand by anyone but Max.
It’s tempting, even in retrospect, to invoke self-righteous arguments for maintainability. But we should be embarrassed doing so given PayPal’s, Max’s, and the rest of The Mafia’s subsequent success.
Incentives matter, but fanaticism comes first.
Seemingly exotic designs should be appropriately discounted by the architect’s level of determination and personal capacity. That doesn't mean we should be obscure on purpose. If we can have elegance too, then great. But authority comes first.
Software recognizes the importance of authorship in its aristocracy. The Bell Labs academics. The Masters of Doom. The Web 2.0 champions. The Unicorn’s various jockeys.
We'd do well to push this ideal further down the stack. To make the top value of our Cultures: extreme and obsessive ownership above all. To insist on taking responsibility.
The levers get longer.
Prose has had the luxury of being cheap. The highest cost is time. Keyboards and paper round to free.
If AI provides the lever described by its weakest advocates, the consequences will be similar in software. What was always true about authority and ownership will be unveiled. Individuals will wield more complexity, to greater effect. Their solutions may be broadly useful, but their implementations will be bespoke and more difficult to shard. It's easier to verify than to solve.
If Jeff Dean, Gemini, and no one else create the next Google, Jeff becomes more of a linchpin, not less. Jeff isn’t obligated to make his implementation accessible to any collaborators, because he has none except Gemini, who Jeff informs with perfect knowledge. His ideas come to life without compromise.
If a dozen such duos are agglomerated into a firm, complexity compounds further. Onboarding into those small groups is going to be proportionally difficult, but maybe also pointless.
The future of software does not look like better committees, but like fewer, denser minds carrying more of the burden end-to-end. Not because collaboration is bad, but because coherence is rare. Authorship is self-enforced coherence, or at least the attempt thereof.
In that sense, software has always been prose. We just pretended it was masonry because masons were abundant, while authors were scarce. AI doesn’t change this so much as it removes the excuses and stimulates supply.
When the cost of expression collapses, what remains expensive is judgment. What twitter pundits have been calling "taste". Software de Sazón. But it's not just about promoting worthy goals above all. Idea guys aren't going to get revenge for the Revenge of the Nerds. Instead, it's about empowering individuals to take full responsibility for ideas and their execution. Drudgery goes to zero, but the creative burden remains the same.
In the end, the job is as it has always been: to hold a complicated thing clearly enough, for long enough, that it becomes real. Then, to wait and see if that reality is any better than before. There's fewer and fewer places to hide from that fact.
The technician's days are numbered.
The author's are just beginning.