I remember the days of non-iterative software development. Teams would start churning out features from day one and quality was a worry for during the “testing phase”. The last few months were always spent on bug fixing and getting late feedback. Contracts for these fixed-price projects would invariably contain a clause about quality. “The project would be considered ready for Go Live if it contained at most 15 medium bugs and no high-priority ones.“

Software developers turned a list of requirements that the customer might want into a list of bugs that they probably wouldn’t fix one day. It wasn’t uncommon for a test report to list hundreds of bugs on a large project.

Late feedback meant we saved all defects until the end of the project.

Iterative, incremental development changed this. We put software in the hands of the users almost as soon as it was written. That means feedback and bug reports come into play from the start of the development cycle.

Early feedback is a good thing, but a lot of teams still seem to stick to the old ways of collecting bugs for a rainy day. I’ve seen teams plan “hardening sprints” just to squash that list.

The thing is: adding bugs to the backlog is like keeping expired food in your fridge. You either eat it now, or you throw it away.

Mature teams often have a Bug First policy. Whenever a new issue is reported, we ask ourselves the question “do we care about fixing this?”. If the answer is Yes, we do it immediately. If we don’t do it immediately, the answer is No. The alternative is stocking your fridge with expired food.

In my experience there are but a few exceptions to this rule. Maybe we are rewriting the Exporter completely and don’t want to fix any of its bugs in the old version. That makes sense. Maybe our one Data Scientist left and we’re waiting for their replacement. That’s valid.

But more often than not, the reason for not fixing bugs right away is: it messes up our short-term plan. That’s a terrible excuse.

A Bug First policy increase software quality, team morale, and predictability of planning. It’s one of those silver-coated bullets that’s highly recommended.

It’s also a straightforward place to start improving your software delivery today.