Bug MuseumEst. 2026

About

Six bugs, without the name tags.

I kept running into the same shape of problem: the fix is easy to show and the reasoning is not. So I collected six defects from my own project work, rebuilt each one as something you can operate, and left the working out attached.

Based on bugs encountered during real project work. Identifying project details have been changed, and each behaviour is reproduced here as a deterministic simulation.

Honesty

What is real and what is modelled

Real

  • The debugging cases. Each one is a defect I actually ran into, fixed, and had to explain — including the fixes that were correct and turned out not to be the end of it.
  • The reasoning. The root cause, the order the fixes happened in, and why the first one was not enough are all accounts of what really occurred.
  • The tests. Every regression test linked from an exhibit is a test in this repository that runs on every push, and the excerpts marked “from this repository” are copied from it.

Modelled

  • The demonstrations. Nothing here talks to a server, a microphone or a model API. Each simulation re-implements the mechanism so you can drive it.
  • The code excerpts. They are minimal reproductions of the pattern being described, written for this museum. They are labelled “minimal reproduction” and are not presented as quotations of anyone's source.
  • The content inside the simulations: page titles, drill names, the three fill-in-the-blanks. Written here, not lifted from anywhere.
  • The clocks. Time zones, backoffs and 180ms ticks are modelled deterministically so the exhibit behaves identically for every visitor and on every test runner.

Anonymised on purpose

Why there are no project names here

  • The original projects were mine, but they were not the point, and a debugging story does not need a name attached to be useful.
  • Some of them are still in use, and a museum that walks visitors through their past defects is not a fair way to represent working software.
  • The technical setting is what a reader needs. “A mobile drawer in a study interface” explains everything the case turns on; the product name explains nothing.

So each exhibit is labelled by its technical setting instead: Learning interface, API resilience layer, Daily practice tracker, Voice session, Multi-tab account flow and Guided coding exercise. Those are descriptions, not products. None of them is the name of an application, here or anywhere else.

Evidence standard

Five rules I held myself to

  1. Evidence you can open, or none claimed. Every exhibit links to its own definition, its simulation, and the test that pins it — all in this repository. There are no citations you cannot check, because there are no citations to anywhere else.
  2. No composite cases. Nothing here is two half-remembered incidents merged into a better story. One exhibit, one defect, one fix history.
  3. Say when the evidence is thinner. One case is modelled rather than driven in a real browser, because the API it depends on does not exist in a test environment. Its exhibit says so in the section where the test would otherwise be.
  4. Say when the simulation diverges. Every display case carries a note under it explaining what is reproduced rather than run, including where a delay was shortened to keep the demonstration bearable.
  5. The first fix stays in the record. Where a fix was shipped and turned out to be incomplete, it is on the wall next to the final one. That is the interesting part.

This site

How it is put together

Exhibits are plain data files, one per case, validated on every test run — a link that points outside this repository fails the build, and so does an excerpt that claims to be quoted without saying from where.

The museum is open source, so every claim on this site can be checked against the file that makes it.

No analytics, no cookies, no tracking of any kind. Start at the gallery.