Day 5 – Ditch the Bug Log

The goal of this sprint is to cut a release. It contains a few features, Install Packs and some outstanding bugs. Its the bugs I fear most. Things are starting to get tense as we realise things aren’t as complete as they should be. People slip into old habits when the pressure gets up and there is even talk of “pulling the release”. We won’t pull the release but we might pull a few low value features.

It is too easy to underestimate the cost of the bugs. Bugs created during development distract us from creating new stuff. Bugs caught after the sprint require a soul destroying period of bug fixing before the release. Bugs caught by the customer at best require patches or at worst loose you the customer

TDD requires more coding but after all that’s what we are paid to do! Automated acceptance tests can also be interesting to code using tools like watir. They both give us a safety net that gives us courage to re-factor rather than bolt on new functionality. So why don’t we do it?

What about having no bug log at all? If we have nowhere to record bugs we have to fix them immediately. This should be disruptive enough to ensure something is done about the bugs but not as soul destroying as not being able to release a product due to a huge backlog of bugs. It might slow down development but if you wait till something is really complete (ie bug free) before moving on to the next thing you at least know where you are.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: