Don’t track bugs, fix them by Allen Holub caused a stir recently when Holub tweeted about not tracking bugs. What a great idea. In my personal projects I always take the time to clear bugs as I find them. I just don’t want to track a bug list for a hobby!

But why not at work too?

It reminded me of the early days of Relentless when we were a small rag tag bunch of game developers who wanted to do things differently. We needed a system to track bugs but we also had a no known bugs policy. I hacked together a Bugzilla server to hold the data. We printed out bugs on a daily basis and fixed them before moving on to features. The novel thing we did was to also keep all the features in the same “bug” database. Essentially, a feature became a bug (as it was unimplemented and was therefore untestable).

I discovered that if you think of it like this, the app starts as a bug description - app does not exist - so you fix that by creating an executable and move on from there.

By maintaining a “bug” list in the same system as the feature list, we were able to treat them in exactly the same way. Work was done in priority order and we frequently reviewed the entire database (by printing it out no less) to reprioritise. Bugs were not tolerated and incomplete features were always flagged off when the game was sent to the publisher.