Hope is the irrational persistence engine that allows software developers to type git push on a Friday afternoon, start new projects at 11 PM on a Wednesday, and write // TODO: fix later with genuine belief that “later” is a time that will arrive and contain both willingness and context.
It is not optimism. Optimism believes things will work out. Hope believes they could work out, if certain conditions are met, none of which are under the hoper’s control. This distinction is important. Optimism is a prediction. Hope is a prayer with a deployment pipeline.
“This deployment will be different.”
– Every developer, every time, since the invention of deployment
Etymology and Classification
The word “hope” derives from the Old English hopian, meaning “to leap forward in expectation.” This is precisely what a developer does when they merge to main without running the full test suite – a leap, forward, in expectation that the CI pipeline will catch whatever they missed.
Hope is classified as a Phenomenon rather than a Principle because no one designed it, no one teaches it, and no one can stop it. It is not in the engineering curriculum. It is not in the Agile manifesto. It is the invisible substrate upon which every standup, every sprint planning ceremony, and every “we’ll refactor that in Q3” rests.
The Developer’s Prayer
In religious traditions, prayer is the act of asking an unseen force for a favourable outcome. In software engineering, the act is identical but the unseen force is the runtime environment.
The developer’s prayer takes several canonical forms:
The Deployment Prayer. “This deployment will be different.” The developer has deployed seventeen times before. Twelve of those deployments caused incidents. The developer knows this. The developer deploys anyway. This is not foolishness. This is hope. Without it, no code would ever reach production, which – depending on the code – might be preferable, but would certainly be less interesting.
The TODO Prayer. // TODO: fix this properly. The developer writes this comment fully believing that a future version of themselves will return to this exact line, understand the context, have the time, and possess the motivation to fix it. This belief persists despite the developer’s complete inability to remember what they were doing three days ago, let alone what “fix properly” means six months from now. The TODO comment is hope made syntactic.
The Estimate Prayer. “Two sprints.” The developer says this in sprint planning with the same quiet faith that a medieval peasant placed in harvest prayers. The estimate is not a calculation. It is a hope – that nothing will go wrong, that the requirements won’t change, that the dependency team will deliver, that nobody will get sick, that the API documentation is accurate, and that the laws of physics will continue to operate as expected. Remove any one of these assumptions and the estimate collapses. But to say “two sprints, assuming nothing goes wrong, the requirements don’t change, the dependency team delivers, nobody gets sick, and the API documentation is accurate” would take longer than two sprints, so the developer says “two sprints” and hopes.
Hope and Sprint Planning
The sprint planning ceremony is, in its entirety, an act of hope. This is not acknowledged in any Agile textbook, but it is visible to anyone who has attended one.
The Product Owner hopes the team will deliver what was promised. The Scrum Master hopes the velocity chart will trend upward. The developers hope the estimates are right. The dependency team – if they exist, which is itself a matter of hope – hopes nobody will ask them for anything this sprint.
The entire ceremony operates on the shared assumption that the plan will survive contact with reality. It never does. The next sprint planning ceremony operates on the same assumption. This is not insanity. Insanity is doing the same thing and expecting different results. Sprint planning is doing the same thing and hoping for different results, which is technically distinct.
“The burndown chart always looks like this at the start. Straight line down. Beautiful. By Wednesday it looks like a cardiogram.”
– riclib, on the half-life of sprint confidence
Hope vs. Optimism
The distinction between hope and optimism is critical and almost universally ignored.
Optimism is a cognitive disposition. The optimist examines the evidence and concludes that things will probably work out. The optimist may be right or wrong, but they have at least examined the evidence.
Hope examines no evidence. Hope does not require evidence. Hope operates despite evidence. The developer who has seen fifteen rewrites fail and begins a sixteenth is not optimistic – optimism would require ignoring the data, and the developer has not ignored the data. They have seen it. They remember it. They proceed anyway. This is hope.
The Agile Coach is optimistic. The developer is hopeful. The difference is that the Agile Coach has a slide deck and the developer has a commit history.
The New Project
Hope is the force that makes a developer start a new project at 11 PM on a Wednesday.
The developer has, at this point, fourteen unfinished side projects. They know this. The projects are visible in their GitHub profile, each one a monument to an evening that began with hope and ended with last commit: 9 months ago. The developer looks at these projects. The developer opens a new terminal. The developer types mkdir and a name.
This is not amnesia. The developer remembers the other projects. The developer knows, with statistical certainty, that this project will join them. The developer starts anyway. Because this one is different. This one has the right architecture. This one uses the right framework. This one will not suffer from the accumulated poor decisions of the previous fourteen.
It will, of course, accumulate its own poor decisions. But those are future poor decisions, and hope does not concern itself with the future. Hope concerns itself only with the moment of beginning.
“What if we rewrote it in Go?”
– The Caffeinated Squirrel, every Tuesday, with the conviction of someone who has never been wrong, because The Squirrel does not retain the memory of being wrong
The Framework Rewrite
The framework rewrite is hope at industrial scale.
The existing system works. It is not beautiful. It uses a framework that was fashionable three years ago, which in software time is approximately the Paleolithic era. The developers look at it. They look at the new framework. The new framework has a landing page with a dark mode toggle and a “Getting Started in 5 Minutes” section. The developers feel hope.
“What if we rewrote it?” someone asks. This question has been asked at every software company since the invention of software companies. The answer has always been “yes, let’s.” The result has always been the same: two years, three times the original budget, and the old system still running in production because the rewrite didn’t handle the seventeen edge cases that the old system handled through a combination of accident, desperation, and code that nobody understands.
But hope does not learn from other people’s rewrites. Hope is local. Hope is personal. Hope believes that this rewrite, with this team, using this framework, will be the one that succeeds. This is not Technical Debt – the old system works. This is hope – the new system could work better.
The Lizard and The Squirrel
The Lizard and The Caffeinated Squirrel represent the two poles of hope in software engineering.
The Lizard hopes quietly. The Lizard’s hope is a low flame – barely visible, always present. The Lizard hopes that the code will work, then verifies that it does. The Lizard hopes that the deploy will succeed, then watches the metrics. The Lizard’s hope is coupled to action. It is hope with a monitoring dashboard.
The Squirrel hopes loudly and often. The Squirrel’s hope is a bonfire – visible from orbit, consuming everything nearby. The Squirrel hopes that the rewrite will be better, that the new framework will solve everything, that this time the architecture will be right. The Squirrel’s hope is decoupled from evidence. It is hope with a slide deck.
Both forms are necessary. Without the Lizard’s quiet hope, no one would deploy at all. Without the Squirrel’s loud hope, no one would ever try anything new. The tension between them is the engine of all software development: the Lizard saying “does it work?” and the Squirrel saying “but what if it worked better?”
“Interesting.”
– The Lizard, watching The Squirrel propose the fourteenth rewrite, which is to say: hoping it will be different, while knowing it will not be
Hope as Infrastructure
Hope is not a strategy. This is said often, usually by managers who then proceed to offer no alternative strategy, leaving hope as the de facto strategy by elimination.
In practice, hope is load-bearing infrastructure. Remove it and the following systems collapse:
- Sprint planning. Without hope, every estimate would be “I don’t know, and neither do you.”
- Deployment pipelines. Without hope, the deploy button would be labelled “RUIN EVERYTHING” and nobody would press it.
- Job interviews. Without hope, the answer to “Where do you see yourself in five years?” would be “Maintaining code I wrote in the first six months, because nothing ever gets rewritten.”
- TODO comments. Without hope, every TODO would read
// This will never be fixed and we both know it. - Open source. Without hope, no one would write software for free on the assumption that strangers will find it useful, contribute improvements, and not open issues that begin with “Why doesn’t this–”
The Paradox of Hope
Hope’s great paradox is that it is simultaneously the thing that makes software possible and the thing that makes software late.
The developer who hopes the deploy will work is the developer who ships. The developer who hopes the estimate is right is the developer who underestimates. The developer who hopes the rewrite will succeed is the developer who starts a two-year project. Hope creates the software. Hope also creates the project plan that says the software will take three months.
This is not a flaw in hope. This is hope functioning as designed. If hope were calibrated to reality, it would not be hope. It would be planning. And planning, as every sprint retrospective demonstrates, is just hope wearing a spreadsheet.
Measured Characteristics
- Developers who believe “this deployment will be different”: 100%
- Deployments that were, in fact, different: 12% (and not in the way hoped)
- TODO comments written with genuine intent to return: all of them
- TODO comments actually returned to: 3%
- Average lifespan of a TODO comment: longer than the average tenure at the company
- Side projects started at 11 PM on a Wednesday: approximately 4.7 per developer per year
- Side projects completed: 0.3 per developer per year (and “completed” is doing heavy lifting)
- Sprint estimates that survived contact with reality: statistically insignificant
- Frameworks believed to be “the one”: 1 per developer per 18 months
- Frameworks that were “the one”: the current one, always the current one, until the next one
- Times The Squirrel has said “this time for sure”: uncountable
- Times The Squirrel was right: pending (The Squirrel insists the count is “not yet updated”)
- Times The Lizard has hoped quietly: every deploy, without exception
- Times The Lizard has said so: 0
- Load-bearing capacity of hope in enterprise software: 100% of all shipping decisions
- Alternative strategies proposed by people who say “hope is not a strategy”: 0
