Graybeard’s thesis is that software drives people insane — not in a pathological sense, but structurally. The conditions around it are unusually effective at making competent adults lose their sense of proportion, and he has watched it happen from enough angles to stop believing it is a personality problem.
The mechanism is invisible cost. Move a kitchen mid-build and everyone sees the boarded walls and rerouted plumbing; the expense is physically undeniable. Move a kitchen in software and the cost hides inside systems that are already hard to reason about, accumulating quietly through context switching, regression risk, and architectural erosion.
Worse, cheap and expensive changes look identical from the outside:
- An hour of real work and a change that ripples through the whole system are both sold as “quick”
- Software has almost no natural friction between an idea and its implementation
- Because there is no visible dust, it is easy to pretend the change was free — and sometimes it genuinely is, which makes the habit worse
Then the vocabulary takes over. “Could” becomes “should,” and “should” becomes “why isn’t it done yet?”
- Everything is urgent because everything can move quickly
- Every technical decision becomes ideological, because dozens of approaches are plausible
- Every slowdown looks like a crisis, because someone somewhere is supposedly moving faster
The sharpest observation is about levers. There is no definition of “done” in software — the button could be better, the query faster, the abstraction cleaner, the product expandable. If you want there to be, there is always another lever within reach. Organizations surrounded by levers start pulling them, often out of fear, board pressure, or simple absence of anything better to do. And the same behavior gets rebranded as virtue: the founder changing direction is “responding to the market,” the manager pushing speed is “execution focused,” the engineer adding a service mesh is “thinking about scale.”
Complexity gets its own pull, because complicated systems make ordinary problems look serious. A CRUD app that stores records is boring; a distributed event-driven platform sounds like you are building NORAD. Work creates importance, importance creates status, and eventually the system exists partly to support the organization that exists partly to support the system.
The prescription is not slowness — that would just be another ideology. It is proportion: leaving things alone is an underrated engineering skill, the framework is often fine, the architecture rarely needs to anticipate a billion users, and most software really is a glorified spreadsheet. Graybeard means that as a compliment.