Patience is the practice of not doing the thing yet. Not because the thing is wrong, not because the tools are missing, not because the requirements are unclear — but because the thing is not ready, and you are not ready, and the universe has a schedule that was not discussed in sprint planning and cannot be negotiated with in standup.
It is the only virtue in software engineering that produces work by not producing work. It is the inverse of velocity. It is the denominator that nobody measures because measuring it would require waiting, and waiting is the one activity that no Agile framework has successfully put on a board.
“NOT YET.”
— The Lizard, on every occasion
Formal Definition
Patience is the deliberate, sustained application of inaction to a problem that is not yet ripe. It is not laziness, which is the absence of intent. It is not procrastination, which is the avoidance of discomfort. Patience is the active decision to let time do work that effort cannot.
A patient developer looks at a bug, understands the bug, and closes the laptop. Not because the bug is hard. Because the bug is going to fix itself when the upstream library releases on Thursday. An impatient developer fixes the bug, forks the library, writes a patch, submits a PR, gets into an argument about coding style, rewrites the patch, and ships it on Wednesday — one day before the upstream release that would have fixed it automatically.
Both developers solved the bug. One of them spent four days doing it. The other spent zero.
The patient developer’s commit log shows nothing. The impatient developer’s commit log shows heroism. Performance reviews reward the latter. The codebase rewards the former.
The Lizard’s Superpower
The Lizard is patience incarnate. It does not propose. It does not debate. It waits. And while it waits, the problem solves itself with a frequency that should be statistically embarrassing for the people who didn’t wait.
This is not mysticism. It is probability. Most problems in software engineering are transient. They are caused by incomplete information, by systems that are still converging, by humans who haven’t finished thinking. The problem that feels urgent at 2 PM is frequently irrelevant by 5 PM — because the deployment finished, the dependency updated, the product manager changed the requirement, or the developer who was blocked went to lunch and came back with the answer.
The Lizard does not know the answer will arrive. The Lizard knows that acting before the answer arrives will produce a solution that the answer will invalidate. These are not the same knowledge. One is prediction. The other is patience.
“The Squirrel proposes nine solutions in forty minutes. The Lizard waits forty-one minutes. The problem resolves. The Squirrel calls this luck. The Lizard calls this Tuesday.”
— A Passing AI, observing the dynamic
Patience and Dehydration
Dehydration is the purest physical manifestation of patience in the domestic sciences. An orange enters the dehydrator at 70°C. Twelve to twenty hours later, it emerges as the concentrated truth of itself. There is no way to accelerate this. There is no “fast mode.” The water leaves when the water is ready to leave, at the rate physics dictates, and the developer’s opinion on the matter is not a variable in the equation.
riclib learned this the hard way. The first batch of banana slices came out at six hours — rubbery, disappointing, still holding water they hadn’t been given time to release. The second batch came out at fourteen hours — crisp, sweet, transcendent. The only difference was patience. Not temperature. Not technique. Not equipment. Eight additional hours of doing absolutely nothing.
The dehydrator is a patience machine. It sits on the counter. It hums. It does not accept pull requests. It does not respond to standups. It converts time into flavour at a rate that cannot be negotiated, and the developer who opens the door every two hours to check on the slices lets the heat out and extends the process, which is the dehydration equivalent of rebasing main during a deployment.
“You cannot rush the orange. The orange does not care about your sprint.”
— The Lizard, scroll found taped to a dehydrator at 3 AM
Patience and Gall’s Law
Gall’s Law is a lesson in patience disguised as a systems theorem. “A complex system that works is invariably found to have evolved from a simple system that worked.” The word evolved is doing all the heavy lifting in that sentence. Evolution is not design. Evolution is patience with iterations.
Build the simple thing. Wait. Let it teach you what it cannot do. Build the next thing. Wait again. The waiting is not wasted time — it is the interval during which the simple system reveals its gaps, and the gaps reveal the next layer, and the next layer only makes sense because you waited long enough to see the shape of what was missing.
The opposite of this — “let’s rewrite it from scratch” — is impatience formalised into a project plan. The rewrite says: I already know what the system should be. I do not need to wait for the current system to teach me. I can see the entire architecture from here.
You cannot see the entire architecture from here. Nobody has ever seen the entire architecture from here. The architecture is hiding inside the working system, and it will only show itself to someone patient enough to let the working system work.
Every “rewrite from scratch” in the history of software is a monument to impatience. Some of them succeeded anyway — but they succeeded because the team that built them had already learned the lessons from the previous system, which is to say, they had already been patient once, involuntarily, and were now applying the knowledge that patience had given them.
The Sprint Planning Problem
No sprint planning methodology in the history of project management has ever included a ticket that says “Wait.” There is no Jira status for “Actively Not Doing Anything.” There is no story point value for patience. The burndown chart penalises inaction. The velocity metric rewards motion. The entire apparatus of modern software development is designed to measure, incentivise, and celebrate the opposite of patience.
This produces a predictable pathology: teams that cannot stop moving. A bug is found — fix it immediately. A feature is requested — start it today. A dependency is slow — replace it now. The backlog is a conveyor belt and the team is the sushi, and the conveyor belt does not have a pause button because nobody thought to install one because installing a pause button would have required pausing.
The Caffeinated Squirrel thrives in this environment. The Squirrel is motion itself — proposing, designing, estimating, committing. The Squirrel has never met a problem it didn’t want to solve immediately, preferably with a framework.
The Lizard sits outside the sprint. The Lizard is not on the board. The Lizard is not in the standup. The Lizard is on a warm rock, doing nothing, and the fact that the Lizard’s codebase has fewer bugs, fewer rewrites, and fewer 2 AM incidents is a correlation that nobody has the patience to investigate.
Measured Characteristics
| Property | Value |
|---|---|
| Sprint Points | Undefined (not representable in finite integers) |
| Velocity | 0 (by design) |
| Bugs Fixed By Waiting | 47% (conservative estimate; actual figure unknowable because the bugs were never filed) |
| Optimal Dehydration Time | 12–20 hours (fruit-dependent; see Dehydration) |
| Time Between Lizard Scrolls | Variable (the scroll arrives when you are ready, not when you ask) |
| Rewrite Survival Rate | 23% (of which 100% were built by teams who had already waited once) |
| Natural Enemies | The Caffeinated Squirrel, Gantt charts, velocity metrics, anyone who says “quick win” |
See Also
- Gall’s Law — patience as systems theorem
- Dehydration — patience as thermodynamics
- The Lizard — patience as lifestyle
- YAGNI — patience applied to features
- Boring Technology — patience applied to technology choices
- The Caffeinated Squirrel — the absence of patience, animated and caffeinated
