“Software drives people insane”: the case for leaving things alone

Software does not make people ill, but the conditions around it can make otherwise reasonable adults lose their sense of proportion. That is the argument of an essay published on the Graybearding blog, whose author calls it a pet theory: software drives people insane.

A glorified spreadsheet, and a lot of levers

Strip away the branding and the architecture diagrams, the essay says, and most software is remarkably boring — a form here, an API endpoint there, some permissions, calculations, workflows and a database, perhaps a queue if something needs to scale. Most software, harsh as it sounds, is still a glorified spreadsheet.

The danger lies in the combination: speed, money, complexity, abstraction and almost unlimited freedom to change your mind. Building a house offers natural friction — decide halfway through framing that the kitchen belongs on the other side, and boards have already been cut and plumbing has been run. In software that cost hides inside people’s heads and inside systems that are already hard to reason about, so the move looks like a simple fix while the expense accumulates quietly through context switching, regression risk and architectural erosion.

From “could” to “why isn’t it done yet?”

Because changing software really can be cheap — sometimes — every cool idea that sounds super quick gets added to the roadmap with urgency. Could becomes should, the author writes, and should becomes why isn’t it done yet? Everything feels urgent because everything can move quickly; every technical choice becomes ideological because dozens of plausible solutions exist; every slowdown looks like a crisis because somebody else is supposedly moving faster.

He points to a missing definition of done. A carpenter eventually puts down the hammer because the cabinet exists, while software can always be improved: the button could be better, the query faster, the abstractions cleaner. Surrounded by levers, software organisations eventually start pulling them — sometimes because something is genuinely wrong, sometimes because they are scared, because the board wants growth, or because a competitor shipped something.

The case for proportion

Complexity fills the vacuum. A boring application that stores records sounds unimpressive, while a distributed event-driven platform with a service mesh and a realtime synchronisation layer sounds like building NORAD. Sometimes the complicated thing is needed, the author concedes; most of the time it probably is not — but complexity provides psychological rewards that simple systems do not.

The remedy is not slowness for its own sake, which would be just another ideology. It is proportion: not every problem is existential, not every idea belongs on the roadmap, not every abstraction deserves to exist, and not every slowdown requires intervention. Leaving things alone is an underrated engineering skill — the database does not always need replacing, the framework is often fine, and customers, engineers and businesses all need time. Useful software, the essay concludes, is enough.