Fix bugs when you find them

As soon as you see a bug you fix it. Do not continue on. If you don’t fix your bugs your new code will be built on a buggy codebase and ensure a stable foundation.

John Romero

How many bugs have you punted on because it’s too hard to figure out the downstream implications of fixing something?

How many known issues does your customer support team have notes on?

How many customers are really affected by those “edge case” bugs languishing in the “could” category in JIRA?

How many of your runbooks read like Choose Your Own Adventure novels?

How many flaky tests block your builds every day? Shit, how many builds are just slowed down because you automated the process of re-running the flaky tests instead of fixing the root cause?

You’re not alone. We all put up with this kind of friction and waste, most often trading it for the feeling of progress we get by writing new code.

In the 1990s, during a hyper-prolific period where they released 28 games in less than five years, id Software’s policy for bugs was to drop everything and fix them as soon as possible. The result was a track record of games that were technically innovative, genre defining, and of undeniably high quality.

A quarter century later it’s tempting to argue that software delivery is more complicated now, the market is completely different, and that it’s important to weigh up fixing something with doing some other work, like implementing a new feature.

But we know that’s not true. When has putting a fix off until late ever made it safer or easier to ship software? We know that the best time to fix the bug is when we have all the context and we’re free of the weight of future decisions.

Let’s make today the day we get into the habit of fixing bugs when we find them.

Further Reading

The Early Days of id Software – John Romero at GDC Europe, 2016

John Romero’s Principles for Programmers – GitHub repo with collecting the principles described in Romero’s GDC talk

Masters of Doom by David Kushner