An essay titled “Software Drives People Insane” argues that the nature of building software can drive otherwise reasonable people to lose their sense of proportion.
The post lays out a “pet theory” about the industry’s peculiar psychology. It is not about clinical madness, the author clarifies, but about how the conditions surrounding software are “remarkably effective at making otherwise normal people lose their sense of proportion.”
The essay argues that the combination of speed, money, complexity, abstraction, and near-unlimited freedom to change course produces some “really bizarre side-effects.” The author says they have watched this happen “enough times from enough angles” to believe it is not simply a personality problem.
Glorified Spreadsheets
The piece grounds its argument in a blunt assessment of what most software actually is. Strip away the branding and architecture diagrams, the author writes, and most software is “remarkably boring.”
“A form here, an API endpoint there, sprinkle in some permissions, calculations, workflows, and a database somewhere,” the author writes. “Maybe a queue if you need to scale something (or you’re feeling adventurous).”
The conclusion is harsh: “most software is still just a glorified spreadsheet.”
Yet producing this spreadsheet-like output can turn “perfectly ordinary adults into b-tier Bond villains.” The project is never moving fast enough. The plan must remain flexible. Every new feature is the one that matters — until the next sprint. There is always a fresh concern about whether it will work, whether it will scale, or whether the team should be doing something else entirely.
No Dust, No Scraps
The core of the problem, the essay argues, is that software has very little natural friction between an idea and its implementation. The author contrasts this with building a physical house.
If someone decides halfway through framing that the kitchen should move to the opposite side of the building, everyone understands the cost. Boards have been cut, plumbing has been run, and people must tear things apart. “The cost is physical enough that nobody can pretend it doesn’t exist,” the author writes.
Software hides that cost. Moving the kitchen in code might look like a “simple fix,” but the expense accumulates quietly through context switching, regression risk, and architectural erosion. The author points to lost momentum, forgotten assumptions, and endless meetings to “get aligned.”
“No matter the actual complexity, it’s easy to pretend the change was free (as in beer) because there isn’t any visible dust or scraps,” the essay says.
The problem is worsened by the fact that changing software sometimes really is cheap. A useful adjustment might take an hour, while another equally simple-looking request ripples through an entire system and causes failures. That opaqueness creates a habit where every “cool idea” that is “super quick” gets added to the roadmap, often with urgency.
Pulling the Levers
The essay traces a familiar escalation. Someone has an idea in a meeting, and there is little resistance between the idea and reality. Could the screen work differently? Could the company change its business model, chase another customer segment, or build its own event system?
The answer is almost always some variation of “sure, we could.”
Eventually, “could” becomes “should,” and “should” becomes “why isn’t it done yet?” This is where the strangeness sets in. Everything becomes urgent because everything can move quickly. Every decision feels strategic because the theoretical upside can be enormous.
Every technical choice becomes ideological because there are dozens of plausible ways to solve the same problem. Every slowdown looks like a crisis because somebody else is supposedly moving faster. The industry has few natural mechanisms that say when enough is enough.
The author contrasts software with carpentry. A carpenter eventually puts down the hammer because the cabinet exists. Software can always be improved.
“The button could be better, the query could be faster, the abstractions could be cleaner, the onboarding could convert more people, and the infrastructure could scale further,” the essay reads.
The Language of Constant Change
The essay suggests that the industry has developed a vocabulary that makes constant change sound virtuous. A founder changing direction every few days gets mythologized as “responding to the market.” A manager pressuring people to move faster is “execution focused.” An engineer introducing new infrastructure components is praised for “thinking about scale.” A product team rebuilding a working interface is “iterating.” A company abandoning its identity is “pivoting.”
The author concedes that some of this language exists because the underlying motivation is legitimate.
There are times to move quickly, times to pivot, and times when the architecture really does need to change. “What makes software dangerous is how easy it is to confuse the existence of a take-able action with the need to actually take it,” the essay says.
The essay identifies a clear progression in how urgency escalates:
- An idea is raised in a meeting with no immediate cost visible
- “Could” becomes “should” because the change seems cheap
- “Should” becomes “why isn’t it done yet” as urgency builds
- The project is never fast enough, and every feature is the one that matters
- The industry’s language — pivoting, iterating, scaling — makes the churn sound strategic
The Missing Definition of Done
The essay points to a structural gap in software work: there is no obvious definition of “done.” The author notes that a carpenter eventually stops because the cabinet exists, but “software can always be improved.”
That openness is one reason software organizations become so neurotic, the essay argues. They are surrounded by levers, “and people who are surrounded by levers eventually start pulling them.”
Sometimes the levers get pulled because something is genuinely wrong. Other times, the author writes, they get pulled because people are scared, because the board wants growth, because a competitor shipped something, because the numbers were flat, or because nobody knows what else to do.
The author’s theory is that software does not just fail or succeed. It changes the people who build it, warping their sense of what is reasonable.
The danger, the essay suggests, is structural. It is not one bad manager or one neurotic team. It is the absence of friction itself, combined with the industry’s vocabulary that mythologizes constant motion — speed becomes “responding to the market,” pressure becomes “execution focus,” and churn becomes “iterating” or “pivoting.”
Key Facts
- Essay title: “Software Drives People Insane”
- Core claim: software’s lack of friction between idea and implementation warps judgment
- Central metaphor: software as “a glorified spreadsheet”
- Contrasting example: moving a kitchen in a house vs. moving it in code
- Key phrase: “the existence of a take-able action with the need to actually take it”
Source: graybeard.ing
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.