Wednesday, September 23, 2009

Respect the elder bugs

Billy (below) is a known old bug. Old enough that it got a name and is well known to the development team.


Bugs, or defects in your software, are not to be treated as pets! Make sure you close bugs fast. Do not get used to bugs.

Agile software development (as typically is the case in the software industry) does create bugs. In fact I came across new Agilists that were surprised because Agile development practices also create bugs; in fact, I have seen more bugs (I am not talking about defects in production) in Agile development than in more traditional development.

But what I expect from a well-working Agile team is that:

  1. The number of bugs in production is low

  2. Bugs are closed very fast


Test Early and Often


Agile development practices such as continuous integration, test driven development, and automation facilitate the quick detection and elimination of bugs. Your customer tests (test validating the customer requirements) will detect any addition or change that breaks an existing test. Your developer tests (tests validating the design of your application) will detect anything that breaks the expected design and behavior of the application.

Disclaimer: for smaller teams, this will be as simple as identify and fix the recognized problem. But for very large teams, it might get a little more elaborated, and a bug is created to track the issue (at times, the issue itself is that there was no automated test).

Scaling Agile


Scaling Agile has a few nuances to it. And bug management and resolution is amongst the development practices that require special attention for a large Agile team. From my experience on a large Agile program, I second the importance to classify bugs by priority and severity.

Elisabeth Hendrickson wrote a very good article about it: Arguing Apples and Oranges.


But even with good bug classification and management, I noticed a few old (pet) bugs living in my large Agile program.

Consider the program had an average rate of 100 new bugs per week. Don’t be alarmed, it is a huge program. Imagine 100 developers continuously integrating code for 200 user stories per week. And an average rate of closing 100 bugs per week.

The depicted scenario can be of a very healthy Agile program. For instance, a small period of regression ensures the production readiness for the system. As Regression I mean the period allocated to stabilizing--fixing the bugs-- the next releasable artifact; not adding new features.

But how is this sample program creating old pet bugs?

Low priority, low severity bugs. These are the bugs that can live a long life.

If the reasoning for deciding the order to attack the bugs only considers severity and priority, you might be creating pet bugs. I did recognize a few elder pet bugs (for this reason) in my large agile program.

My recommendation is to adjust your bug triage formula. You should consider severity, priority, and the age of the bug.

I am sorry Billy (my old pet bug). Even though you were low priority and low severity, it is being embarrassing to have your small –almost inoffensive—existence in the system. I am sorry, but you have to go!

5 comments:

Unknown said...

Hey congrats on the new posting come out
btw i love your blog although i have just stumbled upon it =)
Love the new pictures you got there! Please come visit my site Chicago Business Directory when you got time.

Unknown said...

love your blog! Very cool! Please visit my site
herpes symptoms
when you got time.

Nigel Fernandes said...

I agree with most of this post.

The only point I'd like to add on, is that in a rapidly evolving system, with stories layering functionality,
it may make sense to not fix low priority/low severity issues when first encountered.

Possibly because another story along the way will evolve the code in which the bug exists.

At which point the bug can be closed.

Perhaps open communication to the team about the defects/bugs is critical to identifying this scenario.

I support pragmatic bug fixing. There's a thin grey line between that and broken windows.

angelyu said...

COMPAQ Presario 2103 Series Laptop Battery
COMPAQ Presario 2104 Series Laptop Battery
COMPAQ Presario 2105 Series Laptop Battery
COMPAQ Presario 2106 Series Laptop Battery
COMPAQ Presario 2107 Series Laptop Battery
COMPAQ Presario 2108 Series Laptop Battery
COMPAQ Presario 2109 Series Laptop Battery
COMPAQ Presario 2110 Series Laptop Battery
COMPAQ Presario 2111 Series Laptop Battery
COMPAQ Presario 2112 Series Laptop Battery

Unknown said...

The SBOK guide of scrumstudy.com will give you a clear understanding of how to run effective daily standup meetings. It also provides you detailed information on Agile Project Management methodologies suchas planning/review/retrospective meeting, and how to take advantages of related tools and so on.