Eight rounds of code audits on a small app, and what each one found
Nine of DeskDrawer's releases were stability releases with no new features. This is what eight successive full-codebase reviews actually turned up, including how often a fix caused the next bug.
Look at DeskDrawer's release notes and a pattern is hard to miss. From 1.1.4 onward, most entries begin with some version of "a stability release — no new features".
That is not modesty. It is what the work was.
The rounds#
Eight full reviews of the same codebase, each looking through a different lens.
| Round | Shipped in | Character of what it found |
|---|---|---|
| 1–2 | 1.1.5, 1.1.6 | Blocking the interface thread on icon and thumbnail work; rename and drop targeting the wrong item; configuration safety |
| 3–4 | 1.2.0, 1.2.1 | The desktop New menu misbehaving while icons were hidden; the full shell context menu being truncated; Windows' own dialogs being swallowed |
| 5 | 1.2.2 | Freezes from offline network targets; New item creation on every code path |
| 6 | 1.2.3 | Click-target bugs on board controls; an interrupted save mistaken for a first run; autostart state disagreeing with Task Manager |
| 7 | 1.2.4 | A cross-process object-lifetime bug that could crash explorer.exe |
| 8 | 1.2.5 | A Recycle Bin query stalling on offline network drives; two regressions from round 7's own fix |
Round 7 is the one worth dwelling on. It found a use-after-free across a process boundary that could take Windows Explorer down and restart the desktop. It had been written during round 4, and rounds 5 and 6 had both read that code and not seen it.
What you find is what you were looking for#
That is the central lesson, and it is uncomfortable.
Rounds 5 and 6 were competent reviews that fixed real bugs. They read past the Explorer crash because they were examining threading and configuration integrity, and the bug was neither — it was an object lifetime question spanning two processes. It was found in round 7 because round 7 was specifically about COM interop lifetimes. Nothing else would have surfaced it.
The practical consequence: "the code has been reviewed" is close to meaningless as a quality claim. The useful question is "reviewed for what?" — and the way to find a new class of bug is to pick a lens you have not used yet, not to look harder through one you have.
Fixes cause bugs at an uncomfortable rate#
Round 8 found four issues. Two of them were regressions from round 7's fixes.
Round 7 had narrowed a check about redirected folders to solve a real problem — a OneDrive-backed desktop losing its live file watcher. The narrowed version was still asking the wrong question, and it broke two other cases. That check took three releases to settle, and the story is in Three attempts at one check: reparse points, OneDrive and the desktop.
The Explorer crash was itself introduced by a hardening change in round 4. A change made to improve reliability produced the least reliable moment in the product's history.
Across eight rounds, a fix causing the next bug was not the exception. It was common enough that verification became a separate step rather than something folded into the fix.
Why this got done at all#
Because there is no telemetry in this product, and no way to learn about failures except by finding them — see Shipping with no telemetry, and what it costs. With no crash reports and no usage data, reading the code repeatedly from different angles is not a supplement to the feedback loop. It is the feedback loop.
It is a poor substitute in one specific way: it finds bugs that exist, not bugs that matter. Telemetry tells you which of a hundred rare bugs is hitting a thousand people. Code review tells you there are a hundred rare bugs.
What it means for the product#
Nine consecutive releases of a small utility with no new features is either a warning sign or a statement of priorities. Here it is the second: DeskDrawer paints over the whole desktop, hides the icon layer Explorer owns, and handles your files. The cost of being wrong is high, and shaped like "the user's desktop is broken and they do not know why".
The Limitations page lists what is still known and unfixed. It is a short page, but it is not empty, and it will not become empty.