Denial is the first of the five stages of Grief, the brain’s emergency load-shedding protocol, and the single most common initial response to any sufficiently complex codebase, broken production environment, or project estimate. It is the moment between seeing reality and processing reality — a gap that, in software engineering, can last anywhere from three seconds to an entire career.
Kübler-Ross placed denial first not because it is primitive but because it is structural. The human mind, confronted with information that exceeds its processing capacity, does what any well-designed system does when the load exceeds capacity: it drops the request. This is not failure. This is graceful degradation. The brain has rate limits, and denial is the 429 response.
In software, denial is not an aberration. It is the default state. It is where every developer begins when they open a repository they did not write, a test suite they did not expect, or a deployment pipeline they cannot explain. Denial is the loading screen of comprehension.
“This can’t be the architecture.”
— Every developer, upon inheriting every codebase, throughout all of recorded history
The File That Gets Opened Twice
The canonical moment of denial in software engineering is not dramatic. It is quiet, private, and repeatable.
The developer opens the repository. The developer navigates to the main source directory. The developer opens the first file. The file is four thousand lines long. The developer reads the first hundred lines. The developer closes the file.
The developer opens the file again.
This is the act of denial. The developer is not re-reading the file for comprehension. The developer is re-reading the file because surely — surely — they misread it the first time. Surely the four thousand lines were actually four hundred. Surely the function named doEverything() was actually named something reasonable. Surely the comment on line 7 that reads // I'm sorry was a joke.
It was not a joke. The comment was written by a developer who had passed through all five stages and reached acceptance, and the apology was genuine, and the next developer will add their own apology on line 4,001.
The file-opening cycle typically repeats two to three times before the developer advances to Anger. Some developers report opening the same file up to seven times over the course of a single day, each time hoping that the code has somehow improved in the intervening hours. It has not. It never does. The code is patient. The code can wait.
“It Works on My Machine”
Five words. The most dangerous sentence in software engineering. Not because it is false — it is always true — but because its truth is the problem.
“It works on my machine” is denial distilled to its purest form: the assertion that the developer’s local environment is representative of reality. The developer’s machine has 64 gigabytes of RAM. Production has 8. The developer’s machine runs one request at a time. Production runs twelve thousand. The developer’s machine does not have a user in São Paulo who sends emoji in the authentication header, and the developer’s machine never will, and the developer’s machine does not know what it is missing.
The statement is technically correct — the most devastating kind of correct. The code does work on the developer’s machine. The code does pass the tests. The code does deploy cleanly in staging. And then the code meets production, and production is not the developer’s machine, and the distance between the developer’s machine and production is the distance between denial and reality.
"‘It works on my machine’ is not a status report. It is a confession that you have not tested the thing you are reporting on."
— The Lizard, who has not said “it works on my machine” since 1983, because the Lizard’s machine is production
The phrase has spawned an entire industry of tooling — containers, infrastructure-as-code, reproducible builds — all of which exist to close the gap between the developer’s machine and production. The gap has narrowed. The denial has not. Developers now say “It works in my container,” which is the same statement wearing a different hat.
“The Tests Are Probably Wrong”
When production breaks and the developer’s tests are green, there are two possible explanations: the tests are wrong, or the developer’s understanding of the system is wrong. Denial always chooses the first explanation, because the first explanation does not require the developer to revise their mental model, and revising a mental model is the most expensive operation a human brain can perform.
“The tests are probably wrong” is denial’s masterpiece. It inverts the purpose of testing — the tests exist to tell you when something is broken, and when they tell you something is broken, you reject the message. The developer stares at the failing test and concludes that the test, not the code, is the problem. The developer is a doctor who, upon seeing an abnormal X-ray, concludes that the X-ray machine is miscalibrated.
The tests are not wrong. The tests are almost never wrong. The tests are, in fact, the only part of the system that is behaving honestly, which is why the developer does not trust them — honesty in a codebase is suspicious, because it is so rare.
The Caffeinated Squirrel has never said “the tests are probably wrong,” because the Squirrel does not write tests. The Squirrel considers tests a form of architectural pessimism — if you design the system correctly, why would you need to verify it? This is not denial. This is something worse than denial. This is faith, which is denial that has stopped apologising.
“We Don’t Have Technical Debt”
Individual denial is manageable. It lasts hours or days, and reality intrudes through mechanisms like stack traces, customer complaints, and the on-call pager. Organisational denial is a different species entirely. Organisational denial has a budget, a communications strategy, and a slide deck.
“We don’t have Technical Debt” is the organisational form of denial. It is spoken by managers who have never opened the repository, repeated by directors who have not written code in a decade, and presented on slides by VPs who believe that technical debt is a metaphor and metaphors are not real.
The codebase has not been refactored since 2016. The test coverage is eleven percent. The deployment requires three people, a shared Google Doc of manual steps, and a Slack channel called #deploy-prayers. But there is no technical debt. Because acknowledging technical debt would require acknowledging that decisions were made — by people still in the room, still in their roles, still presenting slides — that were wrong. And being wrong, in an organisation, is more expensive than any amount of technical debt.
The organisational denial cycle is self-reinforcing. The technical debt is not acknowledged, so it is not measured. It is not measured, so it is not funded. It is not funded, so it is not addressed. It is not addressed, so it grows. It grows, so it becomes even harder to acknowledge. The cycle continues until a production outage forces acknowledgement, at which point the organisation skips directly to Anger and blames the engineers who were, themselves, in denial about the same debt.
“We had a meeting to discuss whether we had technical debt. The meeting lasted four hours. The meeting was itself technical debt.”
— An unnamed engineering manager, who was in the meeting, and is still in denial about the meeting
“The Rewrite Will Only Take Two Sprints”
This is denial’s most ambitious form: the denial of scope.
Every developer who has ever proposed a rewrite has made the same estimate. Two sprints. Maybe three. The estimate is always the same because the estimate is not derived from analysis — it is derived from denial. The developer has looked at the existing system, concluded that the complexity is accidental rather than essential, and estimated the time required to build the essential system without the accidents. The estimate is always two sprints, because two sprints is the maximum duration a developer can hold in working memory, and working memory is where denial lives.
The actual rewrite will take between six months and forever. The gap between the estimate and the reality is not a measurement error. It is the distance between the system the developer sees and the system that exists. The developer sees the API surface. The system contains seventeen edge cases per endpoint, four undocumented behaviours that three paying customers depend on, and a date parsing function that handles Icelandic locale formatting because one customer in Reykjavík filed a support ticket in 2019 and nobody has ever removed the fix.
The estimate of two sprints is not an estimate. It is denial wearing a project plan.
“The Squirrel estimates every rewrite at two sprints. The Lizard estimates every rewrite at ’longer than the system you’re replacing took to build, because the system you’re replacing had the advantage of not replacing anything.’”
— Field notes, Yagnipedia Department of Temporal Estimation
The Circuit Breaker Theory
Denial is not stupidity. This distinction is important, because the industry conflates the two regularly and unfairly.
Stupidity is the inability to process information. Denial is the refusal to process information, temporarily, because the volume of information exceeds the brain’s throughput. The distinction is architectural: stupidity is a missing component; denial is a circuit breaker that trips when the load is too high.
You cannot process the full horror of a forty-thousand-line God class all at once. You cannot, on your first day at a new company, absorb the complete topology of a system that seventeen people built over six years with no documentation and three conflicting architectural visions. You cannot, in a single standup, accept that the project you have spent four months on will be cancelled because a VP read an article about AI.
Denial buys time. Denial lets the brain process reality in chunks — today you deny the architecture, tomorrow you deny the test coverage, next week you deny the deployment process. By the end of the month, you have absorbed enough reality to function. Not because the denial ended, but because it worked. It let you onboard without breaking.
The danger is when denial stops being a circuit breaker and becomes a lifestyle. When “this can’t be the architecture” becomes “this isn’t the architecture” becomes “we don’t have architecture problems.” When the circuit breaker trips and nobody ever resets it. When denial calcifies into policy, and policy becomes culture, and culture becomes the slide deck that the VP presents at the all-hands while the engineers stare at their laptops and say nothing, because saying something would require someone to stop denying, and nobody wants to be the first.
The Squirrel and the Lizard
The Caffeinated Squirrel denies that its architecture is over-engineered. The Squirrel’s architecture has fourteen microservices, three message queues, an event bus, a CQRS layer, and a configuration system that requires its own configuration system. The Squirrel does not deny that the architecture is complex. The Squirrel denies that the complexity is unnecessary. Every layer serves a purpose. Every abstraction solves a problem. The fact that most of the problems were created by the previous layer is not something the Squirrel has processed yet, because the Squirrel is in denial about it, and the denial is load-bearing.
The Lizard denies nothing.
This is not because the Lizard is brave, or wise, or enlightened. It is because the Lizard processed all available reality in approximately 1978 and has been operating in a post-denial state ever since. The Lizard opened the codebase, read it, understood it, and accepted it, all in a single compile step. The Lizard does not deny that the architecture is imperfect. The Lizard does not deny that the tests are insufficient. The Lizard does not deny that the deployment process is fragile. The Lizard acknowledges all of this, and then ships anyway, because the Lizard understands something that denial obscures: the system does not need to be perfect. The system needs to work. And it does. And that is enough.
The Lizard has already accepted everything. This is either wisdom or exhaustion, and the Lizard does not find the distinction interesting.
“The Squirrel says ’this can’t be the architecture’ and immediately designs a new one. The Lizard says ’this is the architecture’ and adds a function to the bottom of the file. In six months, the Squirrel’s new architecture will need to be replaced. The Lizard’s function will still be running.”
— riclib, on the relative half-lives of denial and acceptance
Measured Characteristics
- Time spent in denial upon inheriting a legacy codebase: 3 hours to 2 weeks
- Number of times the same file is opened and closed in disbelief: 2-7
- Developers who have said “it works on my machine”: 100%
- Times “it works on my machine” resolved a production incident: 0
- Rewrites estimated at two sprints that took two sprints: 0
- Rewrites estimated at two sprints: all of them
- Organisations that claim zero technical debt: approximately 40%
- Organisations that have zero technical debt: 0
- Test suites blamed for being wrong when production broke: countless
- Test suites that were actually wrong: statistically negligible
- Time the Lizard spends in denial: 0 seconds (total, lifetime)
- Time the Squirrel spends in denial about over-engineering: ongoing (no end date projected)
- Circuit breaker reset time (healthy): 1-4 weeks
- Circuit breaker reset time (organisational): never (requires external incident)
- Comments reading “I’m sorry” found in production codebases: more than you’d hope
