Did the commit agree? What 'done' means when a human and a repository disagree

Thursday standup. "Yep, the timeout fix in charge() — that's done." Everyone nods. The ticket moves to the done column. Nobody opens the repository, because opening the repository to check whether "done" is true would be, in most rooms, a small social violation — an implication that the person's word wasn't good enough on its own.

Here's the uncomfortable question underneath that politeness: what, precisely, made that sentence true? Not the code. The sentence.

The optimism was never really about the estimate

Everyone knows software estimates run long — ask any team how many sprints have shipped exactly on the date first promised, and enjoy the silence. The usual explanation is the planning fallacy, named and measured by Roger Buehler, Dale Griffin and Michael Ross in a 1994 Journal of Personality and Social Psychology paper: people asked to predict how long a task will take consistently lowball it, even when explicitly reminded of how long similar past tasks actually took, because they build the estimate from an idealized best-case plan rather than from their own track record. Their signature finding, from students predicting their own thesis-completion dates, is almost poetic in its excess — students guessed 34 days on average and took 55.

This isn't a quirk of undergraduates predicting their own theses. Magne Jorgensen's 2004 review in the Journal of Systems and Software, surveying decades of studies on how professional software engineers actually estimate effort, found the same optimism running through an industry that's supposed to have grown out of it: expert estimates are consistently too low, experience alone does very little to correct the pattern, and — the detail that matters most here — the bias shows up just as reliably in retrospective self-assessment as in upfront prediction. Being a professional, being senior, having shipped fifty features before this one: none of it reliably inoculates a person against sincerely believing the work is further along than it is. If anything, seniority makes the belief more persuasive to everyone else in the room, including, often, to the person holding it.

What gets missed is that the exact same optimism doesn't stop at the estimate. It keeps going, straight through to the self-report of completion. "Basically done" is a plan-based scenario too — a mental model of the work as essentially finished, built from the same idealizing machinery that produced the original underestimate, and delivered with the same sincere confidence. The planning fallacy doesn't just make people bad at predicting when they'll finish. It makes people bad at noticing, in the moment, that they haven't.

"Done" was never self-evident, and Scrum said so in writing

This is exactly why the Scrum framework requires teams to write down an explicit, shared Definition of Done before the concept is allowed to mean anything. The official Scrum Guide, maintained by Ken Schwaber and Jeff Sutherland, is blunt about why: without one, "Done" is not a fact about the work, it's a private opinion held by whoever's speaking — and a team with several private definitions of "Done" in the same room has, functionally, no definition at all. Two decades of that guidance existing in writing, freely published, and most standups still run on the private version.

The repository doesn't get to have a private opinion

So a commitment resolves against the one artifact in the entire process that cannot politely nod along: the commit log. "I'll have the timeout fix in charge() by Thursday" is a claim with a subject (the function), an owner (the speaker) and a horizon (Thursday). It resolves came_true if a commit by that person touches that subject before that horizon — not if the person says it did, not if the standup vibe was reassuring, not if everyone was tired and wanted to move on to the next item.

This produces exactly the kind of disagreement that makes people uncomfortable the first time they see it, and it's worth sitting in that discomfort rather than smoothing it over: sometimes the human is completely sincere, genuinely remembers finishing the work, and the repository simply shows nothing touching the subject before the horizon. That gap is not an accusation. It is very often just the planning fallacy's second act — the work was real, it happened in a branch, it happened after the deadline, it happened somewhere the commitment didn't specify — and the honest resolution is to say plainly what the evidence shows, not to explain the mismatch away or, just as importantly, to over-explain it into a character flaw. The claim didn't come true on time. That's the whole finding.

Play it forward one more step, because this is where teams usually get nervous the first time. Say the engineer genuinely did fix the timeout — in a branch nobody merged yet, blocked on a review that's been sitting for three days. The commitment still resolves did_not at the horizon, because the evidence the claim specified — a commit, touching the subject, before Thursday — didn't exist yet on Thursday. That can feel unfair in the moment. It isn't a judgment about the engineer's effort or competence; it's a plain statement about what the repository showed at the stated time, which is exactly the kind of boring, literal fact a Definition of Done is supposed to force into the open rather than leave to Thursday's optimism. The review bottleneck that actually caused the delay is real, worth fixing, and completely invisible to a standup that only ever asked "is it done?" and accepted the answer on faith.

"Done" used to mean whatever the speaker remembered doing. Resolved against a commit log, it means something a repository, not a mood, can confirm.

What a commit can't tell you, on purpose

It's worth being precise about the limits here, because overclaiming would be its own kind of dishonesty. A commit touching charge() is evidence that work happened on the right subject before the horizon. It is not evidence that the work actually fixed the timeout, that it didn't introduce a new problem, or that the underlying theory behind it was correct. Those are different claims, resolved by different evidence — production telemetry, not the commit graph — and conflating "a commit landed" with "the claim about the world was correct" would just relocate the original mistake instead of fixing it. The next part of this arc is about exactly that second kind of resolution, and why it belongs to production rather than to git blame.

What changes when people know the repo is the referee

The quiet, second-order effect of resolving commitments this way is not punitive — it's clarifying. When a claim will be checked against something nobody can talk their way around, people naturally start promising things they can point to: a specific function, a specific PR, a specific horizon, instead of a comforting general assurance. That's not people becoming more honest in some moral sense. It's people responding, entirely rationally, to the fact that the room they're speaking in finally has a memory that isn't made of memory.

There's a second-order benefit that only shows up after a few sprints of this, and it's easy to miss because it doesn't announce itself: commitments start getting scoped to what's actually true rather than what's aspirationally comfortable. "I'll have the timeout fix by Thursday" quietly becomes "I'll have a PR up by Thursday, merged by Monday" — not because anyone was told to be more precise, but because the vaguer version kept resolving did_not against a repository that doesn't grade on effort. A Definition of Done, forced by evidence instead of policy, ends up doing exactly what a Scrum Guide always intended it to do. It just took a repository, rather than a facilitator, to actually enforce it.

It's worth being honest, too, about the version of this that goes wrong. If "resolved against the commit log" gets read by a team as "never say you're done unless you're triple-certain," the fix has overcorrected into a different failure — people quietly stop making Thursday commitments at all, retreating into the same unfalsifiable fog Part 21 of this arc warned about. The goal was never maximum caution. It was a claim specific enough that reality, whichever way it went, would have something concrete to check it against. A wrong, specific commitment that resolves did_not is still more useful, to the team and to the person who made it, than a vague one that could never have been checked in the first place.