HathawayField Notes
← All concepts

Software Engineering

4notes

A bug becoming a feature (1972 edition)

I could have fixed it, but it turned out to be important, because if you get two good players they could just volley and play the game forever. And the game has to end in about three or four minutes otherwise it’s a failure as a game. So that gap at the top, again – a feature. So that was sort of a happy accident.

“Happy” primarily in the context of the industry – the goal of an arcade game was, after all, to bring in quarters, and this here was the unexpected equivalent of the zero in a casino roulette game. But I wonder if some of this bugginess/randomness also helped the game feel challenging and surprising, even for skilled players.

unsung.aresluna.org
A bug becoming a feature (1972 edition)

A simplified circuit left a gap the Pong paddles couldn't reach. Fixing it would have let two good players volley forever.

The backlog was always a credit card

An engineer putting a piece of work on their backlog is effectively deferring it to never. It’s important enough to write it down somewhere and document that it exists as a bug or a feature enhancement, but it’s not important enough to act.

Yes, sometimes we ambitiously carve out time to “burn down the backlog”, but do you know what we pick from that list? We pick the interesting work. Interesting to code or interesting because of the impact on the feature. Some kind of interesting briefly elevates this work to relevance. The boring backlog work? You couldn’t pay me.

I’ve avoided keeping backlogs for most of my career because they behave like debt. You put the task on the card, feel good about not losing it, then pay interest every day you don’t do it. Grooming, triage, scrolling past the same broken link for the ninth month: all payment, none of it touching the principal.

Handing the list to an agent changes what the list is for. A backlog became a graveyard because writing work down was cheap and doing it was expensive. Close that gap and it’s a queue again. I still don’t want to keep one, but I’m less sure what I hated was the list rather than the price of acting on it.

randsinrepose.com
R.I.P. Your Backlog

Backlog work is work you've decided not to do. Now there's someone willing to do it.

July 2026

The second 90 percent

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

— Tom Cargill, Bell Labs, via the Ninety-ninety rule

This rule is so true it barely reads like a joke. Anyone who has shipped software has watched a project reach “almost done” and then stay there while the real work finally shows itself.

Not even AI can break it. It changes how quickly we can get through the first 90 percent: scaffolding, boilerplate, tests, happy paths, and enough of the shape of the thing that it feels almost done.

But the second 90 percent still requires human judgment. Someone has to know which rough edges matter, which tradeoffs are acceptable, and when the product is actually right.