Bargaining is the third of the five stages of Grief, positioned between Anger (in which the developer identifies who is to blame) and Depression (in which the developer realises the answer is “everyone, including themselves”). It is the stage in which the developer, having exhausted denial and rage, arrives at the negotiating table and attempts to trade something they have now for something they will need later.
The trade is always the same: quality for time. The terms are always unfavourable. The future always collects.
“Maybe if I just refactor this one module…”
– Every developer, at the precise moment before a partial rewrite becomes a total rewrite
Etymology and Position in the Grief Cycle
Elisabeth Kübler-Ross described bargaining as the stage in which the grieving person attempts to negotiate with fate, God, or the universe – offering behavioural changes in exchange for a different outcome. “If I pray every day, will the diagnosis change?” “If I become a better person, will this not have happened?”
In software, the diagnosis is the codebase. The codebase will not change. The developer prays anyway.
Bargaining occupies a structurally unique position in the grief cycle. Denial is passive – the developer simply refuses to see. Anger is reactive – the developer sees and rages. But bargaining is active. The developer sees, accepts (partially), and attempts to negotiate with reality. This makes it the most dangerous stage, because it produces action. Denial produces nothing. Anger produces Slack messages. Bargaining produces pull requests, and pull requests ship.
The Partial Rewrite
The canonical bargain in software engineering is the partial rewrite.
The developer has inherited a codebase. They have passed through denial (“this can’t be the architecture”) and anger (“who wrote this”). They now sit before the code with the calm desperation of someone who has been told the building is structurally unsound but cannot afford to move.
“Maybe if I just refactor this one module.”
The module is utils.go. The module is always utils.go. The developer will extract a clean interface. They will add tests. They will create a boundary between the good code (theirs, forthcoming) and the bad code (everyone else’s, existing). The refactoring will take two days.
The refactoring takes two weeks because the module depends on three other modules, which depend on seven other modules, which depend on utils.go again through a circular dependency so old it has its own entry in the project wiki. The developer, having set out to refactor one module, has now touched fourteen files, broken the build twice, and written a twelve-page proposal for a complete rewrite.
The bargain was “I will fix this one part.” The cost was everything adjacent to it. The Lizard could have told them. The Lizard did tell them. The Lizard was not consulted.
“The partial rewrite is a gateway drug. Nobody starts with ’let’s rewrite everything.’ They start with ’let’s just clean up this one file.’ The distance between the two is approximately four days.”
– The Caffeinated Squirrel, who has crossed that distance seventeen times and learned nothing, because learning would require remembering
Sprint Negotiation as Institutionalised Bargaining
Sprint Planning is, at its core, a bargaining ceremony conducted between people who want different things and have agreed to pretend they want the same thing.
The Product Owner arrives with a list of features. The list contains more work than the sprint can hold. Everyone knows this. The Product Owner knows this. The team knows this. The Scrum Master knows this. The negotiation begins anyway, because the alternative – acknowledging that the roadmap is fiction – would require a meeting that nobody has the stomach for.
The bargains follow a predictable taxonomy:
The Test Bargain. “We can do it if we drop the tests.” This is the most common sprint bargain and the most consequential. Tests are the first thing sacrificed because their absence produces no immediately visible damage. The damage arrives later, in production, at 3 AM, when the person who agreed to skip the tests is asleep and the person who is awake was not in the room when the bargain was struck.
The Review Bargain. “We can ship by Friday if we skip code review.” Code review is the second sacrifice. It is slow. It creates conflict. It occasionally reveals that the approach is wrong, which nobody wants to hear on a Wednesday when the demo is Friday. Skipping it saves two days and costs two months, but the two months are someone else’s problem and the two days are yours.
The Scope Bargain. “Can we ship without feature X?” This is the only honest bargain. It does not trade quality for time; it trades scope for time, which is a legitimate exchange. The Lizard approves of scope bargains. The Lizard does not approve of quality bargains. The difference is that scope bargains remove work; quality bargains hide it.
The Hardcoding Bargain. “What if we hardcode this for now?” The word “for now” is doing the structural work of a load-bearing wall in this sentence. Remove it and the statement collapses into what it actually is: “What if we hardcode this.” The “for now” implies a future in which the hardcoded value will be replaced with a proper configuration. This future does not exist. The hardcoded value will outlive the developer, the team, the product manager, and possibly the company.
“We agreed to ship without error handling. The errors did not agree to ship without occurring.”
– An incident postmortem, three weeks after a sprint planning session that went fifteen minutes over
The TODO Comment: A Bargain in Amber
The // TODO comment is the purest expression of bargaining in software. It is a contract between the present developer and the future developer, written by the present developer, signed by the present developer, and binding upon the future developer, who was not consulted, did not agree to the terms, and will be busy with something else entirely when the bill comes due.
// TODO: fix this properly
// TODO: handle the error case
// TODO: this is temporary
// TODO: come back and refactor this
// TODO: replace with real implementation
Each TODO is a bargain. The present developer trades code quality for development speed. The future developer pays with debugging time, incident response, and the specific despair of reading a comment that says “temporary” above code that has been running in production for four years.
The average lifespan of a TODO comment exceeds the average tenure of a developer at the company that contains it. This means most TODOs outlive their authors. They are orphaned bargains – debts with no debtor, promises with no promiser, contracts with no counterparty.
“I wrote ‘TODO: fix later’ in 2019. It is 2026. The TODO is still there. I am not. The code is not fixed. The code does not need to be fixed. The code works. The TODO is a monument to a version of me who believed in ’later,’ and I envy that version’s innocence.”
– A developer, reflecting on the persistence of good intentions in a universe that does not reward them
Technical Debt as a Bargain with the Future
Technical Debt is bargaining at the ledger level. Every instance of technical debt is a bargain in which the present team borrows time from the future team, at an interest rate that is never disclosed, on terms that are never written down, against collateral that the future team did not offer.
“We’ll fix it later” is not a plan. It is a prayer. (See Hope, which is the engine that makes the prayer feel reasonable.)
The bargain is attractive because it is asymmetric. The present team gets the benefit – the feature shipped, the deadline met, the demo delivered. The future team gets the cost – the production incident, the onboarding friction, the three-week refactoring that was supposed to take two days. The present team and the future team are often the same people, which makes the bargain a form of self-deception so refined it could be taught in philosophy departments.
Ward Cunningham’s original metaphor described a deliberate, conscious loan – borrowing against future understanding, with a plan to repay. What the industry practises is not a loan. It is a heist. The present robs the future and leaves a TODO comment as a confession.
The Squirrel’s Bargains
The Caffeinated Squirrel is a prodigious bargainer. The Squirrel’s bargains are grand, optimistic, and never repaid.
“I’ll use the framework now and learn it properly later.” The Squirrel adopts a framework based on the README, the landing page, and a conference talk whose speaker had the quiet confidence of someone who has only used it for a demo. The Squirrel will read the documentation later. The Squirrel will understand the lifecycle methods later. The Squirrel will learn why the framework’s author made those particular choices later.
Later never arrives. The Squirrel builds the application on a foundation of enthusiasm and partial understanding. When the application breaks in ways the README did not cover, the Squirrel does not consult the documentation. The Squirrel adopts a different framework. The cycle repeats. Each framework is a new bargain. Each bargain is a new “later.”
The Squirrel’s bargaining is theatrical, public, and passionate. “Just give me two more days and I’ll have the tests.” “The refactoring will pay for itself in a sprint.” “This architecture will scale.” The bargains are sincere. The Squirrel believes every one of them at the moment of utterance. The Squirrel’s memory of failed bargains is, conveniently, poor.
The Lizard Does Not Bargain
The Lizard does not bargain. This is not because the Lizard is wise, though the Lizard is wise. It is because the Lizard sees bargaining for what it is: an attempt to alter the price of something by wanting the price to be different.
The Lizard states the cost. The cost is the cost.
“How long will the refactoring take?” Three weeks. “Can we do it in one?” Three weeks. “What if we cut scope?” Then it is a different refactoring. That one takes two weeks. “What if we skip the tests?” Then it is not a refactoring. It is a rearrangement. That takes three days. The bugs take three weeks.
The Lizard does not negotiate because the Lizard understands that software development is not a negotiation. It is physics. The code takes as long as it takes. The tests catch what they catch. The deploy breaks what it breaks. Wanting it to be different does not make it different. Bargaining with reality does not change reality. It changes only the plan, and the plan was never reality to begin with.
This makes the Lizard unpopular in sprint planning. Accurate, but unpopular.
“Interesting.”
– The Lizard, watching a team agree to deliver eight features in the time it takes to deliver four, with the difference made up entirely of bargains
The Bargainer’s Taxonomy
Not all bargains are equal. Some are strategic. Some are desperate. Some are both.
| Bargain | What Is Traded | What Is Received | Who Pays |
|---|---|---|---|
| “Skip the tests” | Safety | Speed | The on-call engineer, at 3 AM |
| “Skip code review” | Quality | Velocity | The next developer to read the code |
| “Hardcode it for now” | Flexibility | Simplicity | Everyone, forever |
| “Drop feature X” | Scope | Time | The users (honestly) |
| “We’ll fix it later” | Future capacity | Present delivery | Future self, who did not agree |
| “Use the framework, learn it later” | Understanding | Momentum | The developer, when it breaks |
| “Ship without docs” | Discoverability | Deadline | The new hire, on day one |
The only bargain the Lizard respects is the scope bargain, because it is the only one that removes work rather than hiding it.
The Bargain Escalation Pattern
Bargaining, left unchecked, follows a predictable escalation:
Day 1. “Maybe if I just refactor this one module.” A reasonable scope. A clean boundary. A two-day task.
Day 3. “Maybe if I refactor these three modules.” The one module touched two others. The boundary was not clean. It was a seam, and seams connect things.
Day 7. “Maybe if I introduce a new interface layer.” The developer has now written more scaffolding than production code. The original module is untouched. Three new abstractions exist. Tests: zero.
Day 14. “Maybe if we just –” At this point the developer has written a twelve-page proposal for a complete rewrite. They are deep in The Second System Effect, which is where bargaining goes to become Depression.
Day 15. The developer opens utils.go, adds a function to the bottom, and does not refactor the four thousand lines above it. This is Acceptance. Acceptance is not where bargaining succeeds. It is where bargaining stops.
The Friday Deploy Bargain
There is a special category of bargain that occurs exclusively on Fridays after 3 PM: the Friday deploy.
“It’s a small change. It’ll be fine.”
This bargain trades the weekend – not the developer’s weekend, but the on-call engineer’s weekend – for the satisfaction of closing a ticket before the sprint ends. The change is small. The deploy is routine. The monitoring is green. The developer goes home.
The page arrives at 2 AM Saturday. The on-call engineer, who was not consulted about the bargain, discovers that the “small change” interacted with a system the developer did not know existed, in a way that no test caught, because the tests were skipped three sprints ago in a different bargain by a different developer who has since moved to a different team.
Bargains compound. This is the thing about them that nobody mentions in sprint planning.
Measured Characteristics
- Bargains struck per sprint planning ceremony: 4-7
- Bargains repaid per sprint: 0.2 (optimistic)
- Average lifespan of a “temporary” hardcoded value: 4.3 years
- TODO comments that outlive their authors: 73%
- Partial rewrites that became total rewrites: 60%
- Partial rewrites that became abandoned rewrites: 30%
- Partial rewrites that remained partial: 10% (the Lizard’s)
- Sprint velocity increase from skipping tests: 15% (immediate)
- Sprint velocity decrease from bugs caused by skipping tests: 40% (delayed)
- Developers who believe “we’ll fix it later”: 100% at time of utterance
- Developers who fix it later: statistically insignificant
- The Squirrel’s outstanding bargains: uncountable (accruing)
- The Lizard’s outstanding bargains: 0
- Friday deploys that were “a small change” and “fine”: fewer than claimed
- Cost of a bargain, as stated by the Lizard: the cost
