DEV Community

Mahiro Hirakawa
Mahiro Hirakawa

Posted on

Relabeling 22 backlog items moved a progress bar 23 points, and I hadn't shipped anything

Relabeling 22 backlog items moved a progress bar 23 points, and I hadn't shipped anything

A progress ledger I keep for a Rust project tracks work across thirteen categories, a little over a hundred discrete items total, each one marked done or not done. Early on 2026-09-01 it read 31 out of 105, 29.5%. Later the same day it read 55 out of 105, 52.4%. Twenty-four items moved, twenty-three percentage points, in less than a day, on a project where nobody had actually shipped twenty-four things.

They hadn't. When I went back through what actually changed, only two of the twenty-four represented new work completed that day, one demo script getting an independent re-check confirmed, one milestone in a virtual-execution component independently verified. The other twenty-two came from a single relabeling pass on one category, the one covering test and verification coverage across the codebase. Those twenty-two items had been sitting with a status that basically meant "not yet audited," and four separate audit passes that day actually ran against the code, across 481 files and 2,515 test functions, and confirmed the coverage was real. So the label changed from "unchecked" to "checked and clean." That's legitimate work. Four real audits ran. But it isn't the same kind of event as building something new, and the ledger had no way to say so, because "unchecked" and "checked and clean" moved through the exact same status column as "not built" and "built," using the same visual action: a row flips from open to done.

One number in that sentence needs a caveat I'd rather give than be caught omitting. The 2,515 figure was that day's count, and a fuller run the next day superseded it: 2,926 probes passing of 2,988 that exist in source, 59 failing, measured 2026-09-02. I'm leaving both here instead of quietly swapping in whichever reads better, because a ledger that revises its own history is the exact thing this piece is complaining about.

That's the part I keep coming back to. A percentage-complete number, by itself, can't tell you whether the movement behind it was administrative catch-up or actual delivery, if the tracker only has one axis for "progress." Both look identical on a dashboard. Both are real events worth recording. They are not the same event, and treating them as interchangeable means a bookkeeping pass, going through a pile of already-finished work and finally confirming it's finished, can produce the exact same chart movement as a sprint that shipped two dozen new things, and nobody looking at the chart alone can tell which one happened.

There's a second wrinkle in the same data that's worth being honest about, because it undercuts the tidiness of even that fix. A separate tracking effort inside the same project had, independently, built its own denominator that day, 112 items instead of 105, by registering seven newly discovered items that didn't fit cleanly into the original thirteen categories. That 112-item count and the 105-item count were never reconciled. By the end of the day there were two different "official" completion percentages in circulation, neither one aware of the other's updates, and combining them by hand produces a third number, roughly 50.9%, that doesn't appear written down anywhere in either system.

The habit this produced, stated as plainly as I can: if two different kinds of movement, verifying old work versus completing new work, can land in the same status column, split the column before the first relabeling pass happens, not after someone notices the chart jumped and has to reconstruct why. And if a project tracks progress in more than one place at once, somebody has to own reconciling them on a schedule, because the gap between two unreconciled trackers doesn't announce itself. It just sits there being wrong in a way that looks, from a distance, exactly like being right.

Top comments (0)