⏱️ Lectura: 11 min
An engineer who writes as Graybeard published an essay on September 10, 2026, with an uncomfortable thesis: software doesn’t drive people crazy because it’s hard, but because of how cheap it looks to change. His central argument has a name, the hidden cost of software: the gap between what it costs to request a change and what it actually costs to sustain it.
📑 En este artículo
The comparison he uses is physical: moving a wall halfway through construction has a visible cost, there’s rubble and broken pipes. Moving a function in code looks free because it doesn’t leave dust, even though the real cost piles up later, in meetings, migrations, and broken metrics dashboards.
TL;DR
- The essay Software Drives People Insane was published by Graybeard on September 10, 2026, at graybeard.ing.
- The thesis: software mixes speed, money, complexity, and the freedom to change your mind, something other industries don’t have.
- The author describes most software as a glorified spreadsheet: forms, permissions, calculations, and queues.
- Unlike moving a wall on a construction site, changing code doesn’t leave visible rubble, so its real cost stays hidden.
- The ‘it’s possible, it should happen, why isn’t it done’ cycle feeds the sense of constant urgency in teams.
- The essay doesn’t offer a closed solution, but it suggests manufacturing artificial friction, like an explicit definition of done.
- Technical debt and scope creep are the measurable effects of a mechanism that, according to the author, is also psychological.
What Happened
Graybeard, a developer who writes under a pseudonym on his personal blog, published the essay Software Drives People Insane on September 10, 2026. His starting point is a simple observation: he’s seen enough normal people turn into, in his words, ‘second-rate Bond villains’ during product development to rule out that it’s just a personality issue.
The question he asks isn’t technical but organizational: what is it about software, as an activity, that produces that effect so consistently? His answer combines five ingredients that, on their own, are manageable: iteration speed, available money, technical complexity, layers of abstraction, and the nearly unlimited freedom to change your mind midway through. Together, according to the author, they generate strange side effects.
The essay insists that, stripping away branding and architecture diagrams, most software is boring: a form here, an API endpoint there, permissions, calculations, some workflow, and a database. In his words, ‘most software is still a glorified spreadsheet.’ The contrast that interests him is exactly that: how something so mundane in its final form can make the process of building it so tense.
Context and History
The analogy the essay rests on comes from construction. If someone decides, halfway through a build, that the kitchen should move to the other side of the building, everyone understands that decision has a cost: boards have already been cut, pipes already laid, something finished has to be torn out. The cost is physical, so no one can pretend it doesn’t exist.
Moving the kitchen in software can look like a ‘simple fix.’ The work stays just as costly, but the expense piles up quietly. Between context switching, regression risk, and architectural wear, lost momentum, forgotten assumptions, and endless ‘alignment’ meetings show up. Since there’s no visible dust or rubble, it’s easy to believe the change came for free.
The problem gets worse because changing software sometimes really is cheap. One adjustment might genuinely take an hour, while another request that looks identical can spread through the entire system and break things in production. That opacity creates a dangerous habit: any ‘brilliant idea’ that sounds ‘super quick’ gets added to the roadmap, almost always with urgency attached.
That habit is the engine behind the cycle the essay describes: someone has an idea in a meeting, and there’s almost no resistance between the idea and reality. Can we change how this screen works? Can we change the business model, chase a different customer segment, add a new flow, build our own event system? The answer is almost always some version of ‘yes, it’s possible.’ Over time, ‘it’s possible’ turns into ‘it should happen,’ and ‘it should happen’ turns into ‘why isn’t it done yet?’
flowchart TD
A["Someone has an idea in a meeting"] --> B["It's possible to do"]
B --> C["It should be done"]
C --> D["Why isn't it done yet"]
D --> E["Enters the roadmap with urgency"]
E --> AThe diagram sums up the mechanism: without a real friction point, the cycle feeds itself, and each iteration adds a new idea without closing out the last one.
Technical Details: Where the Hidden Cost of Software Hides
The hidden cost of software isn’t abstract, you can see it in a diff. A request that sounds like ‘an afternoon of work’ in a product meeting almost never stays a single line of code once it reaches the repository.
// Before: canceling a subscription is a direct operation
function cancelSubscription(userId) {
db.subscriptions.update(userId, { status: "cancelled" });
}The original request in the meeting was: ‘let’s add a short survey before canceling, to understand why people leave.’ Sounds like a form and a save. Here’s how it actually turns out, two sprints later:
// After: the same function, with the real cost now visible
function cancelSubscription(userId, surveyResponse) {
logSurveyResponse(userId, surveyResponse); // new table, new permission
applyRetentionOffer(userId); // touches the billing service
db.subscriptions.update(userId, { status: "cancelled" });
notifyRetentionTeam(userId); // new queue, new consumer
emitAnalyticsEvent("subscription_cancelled_v2"); // breaks dashboards that read v1
}None of this is an estimation error. Each new line is a reasonable decision made by a different person, at a different time, without seeing the whole picture. Scope creep (the progressive expansion of a project’s scope) rarely arrives as one big request: it arrives as a succession of small requests, each defensible on its own.
⚠️ Watch out: a change being cheap to code doesn’t mean it’s cheap to operate. The debt generated by a ‘yes, it’s possible’ gets paid in incidents, not in the sprint where it was approved.
How to Apply This in Your Team
The essay doesn’t offer a closed recipe, but its diagnosis does point to a way out: if software has no physical friction, you need to manufacture artificial friction in the process, before a request reaches the code. That doesn’t mean extra bureaucracy for its own sake, it means making visible the cost that’s currently hidden.
The simplest tool is an explicit definition of done, reviewed before estimating, not after. ‘Done when it compiles’ isn’t enough: it has to name the downstream systems the change touches.
# definition-of-done.yaml
feature: "cancellation survey"
done_when:
- tests: "covers both the new flow and the old flow"
- rollback: "a flag exists to turn it off without a deploy"
- metrics: "retention dashboards were updated, not just the new event"
- scope: "the billing team approved the change in applyRetentionOffer"
- estimation: "the ticket describes the real cost, not just the original request"This file doesn’t solve the problem on its own, but it serves the same function as rubble on a construction site: it forces the team to name, before starting, what’s going to break. When no one can fill in a row on the checklist, that’s the signal that the ‘quick’ request isn’t quick at all.
Impact and Analysis
The essay’s usefulness, beyond the anecdote, lies in giving vocabulary to a problem most engineering teams recognize but rarely name. The table below compares three typical types of change and where, in each case, the cost that doesn’t show up in the initial estimate hides.
| Type of Change | Visible Cost When Requested | Where the Real Cost Hides | How to Mitigate It |
|---|---|---|---|
| Adding a field to a form | None, ‘it’s just a field’ | Migrations, validations, and reports that already assumed the old schema | Definition of done that includes migrations and dashboards |
| Changing the cancellation flow | An afternoon of work | Billing service, event queues, retention dashboards | Review dependencies before estimating, not after |
| Changing the business model | ‘Just need to change the messaging’ | Entire architecture designed for the previous model | Freeze structural changes per sprint and measure the cost of reverting |
This logic connects to a well-known concept in software engineering: technical debt, understood as the future cost accepted in exchange for a quick solution today. What Graybeard’s essay contributes is the psychological mechanism behind why teams keep accumulating that debt even when they’re aware of it: there’s no natural moment when someone says ‘this is finished,’ because there’s always one more lever within reach.
That absence of an endpoint is, for the author, the root of the organizational neurosis. A carpenter puts down the hammer because the piece of furniture already exists. In software, the button could always be better, the query could always be faster, the abstractions could always be cleaner. The product could always expand into an adjacent market. If you want to, there’s always another lever within reach.
💭 Key point: the essay doesn’t say changing direction is wrong. It says the same decision gets a different name depending on who makes it: a founder who changes course every week ‘responds to the market,’ an engineer who adds new infrastructure ‘thinks at scale.’ The language disguises the same problem.
What’s Next
Graybeard’s essay doesn’t propose an institutional solution, and that’s its limit: it describes the mechanism with precision but leaves each team the task of manufacturing its own friction. His vocabulary, the hidden cost of software, the ‘could to should’ cycle, will most likely circulate in retrospectives and engineering posts as a convenient way to name something that used to only be felt.
For an actual team, the next step isn’t philosophical: it’s auditing the last five ‘quick’ requests that ended up taking weeks and seeing what they had in common. The answer is almost always the same one the essay points to: no one asked, before accepting the request, which downstream systems assumed the previous behavior.
📖 Summary on Telegram: View summary
Try it yourself: next time someone asks for a ‘one-line’ change, ask them to fill in the ‘scope’ row of the checklist before estimating it, and compare how long it takes them to respond.
Frequently Asked Questions
What is the hidden cost of software?
It’s the difference between what requesting a change appears to cost and what it actually costs to sustain in production: migrations, dashboards, downstream services, and the coordination time that doesn’t show up in the initial estimate.
Who is Graybeard?
It’s the pseudonym of a developer who writes on the blog graybeard.ing about engineering culture and software organizations. The essay analyzed here was published on September 10, 2026.
What is scope creep and how does it relate to this phenomenon?
Scope creep is the progressive, unplanned expansion of a project’s scope. The essay describes the psychological mechanism that produces it: each small request is defensible on its own, even if the sum becomes unmanageable.
How do you tell a genuinely quick change from one that just looks quick?
By asking, before estimating, which downstream systems assume the current behavior. If no one in the room can answer within seconds, the change isn’t as quick as it sounds.
Does this only apply to startups or also to large companies?
It applies to any organization where the gap between an idea and its implementation is short, which describes both a three-person startup and a large team with too much technical autonomy.
How does this relate to technical debt?
Technical debt is the future cost accepted in exchange for a quick solution today. The essay explains why teams keep accumulating it even when they’re aware of it: there’s no natural ‘done’ point in software.
References
- Software Drives People Insane, Graybeard: the original essay that lays out the hidden cost of software thesis.
- Scope creep, Wikipedia: definition and examples of unplanned scope expansion in projects.
- Technical debt, Wikipedia: the concept of technical debt and its origin in software engineering.
- Scrum (software development), Wikipedia: context on the ‘definition of done’ practice cited in the article.
📱 Enjoy this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day. @programacion
0 Comments