It’s Not a Bug; It’s a Feature

I know everyone who has worked in, or on, or amongst a development team has heard the saying, “It’s not a bug; it’s a feature.” When said, it is usually followed by some laughter, sometimes remorseful laughter. Heck, you’ll even hear the users beat you to the punch when they say, “That’s a feature, not a bug – right?”

Ding. Ding. Ding! Mr. User, you are absolutely correct!

Anything that goes out the door is a feature of our product (or anything we release to our users is a feature). Now whether the feature improves the value of our product or service, or if it detracts from the value — they are all features. We chose to release our software — we may have known about the problem or we may have known that we did not test enough or we may not have had the awareness of a unique usage scenario – no matter what we chose to release and everything in the product is a feature. Couple the concept of releasing bugs in our code with the premises around technical and design debt, well… now our heads are exploding as producers of software!

Now, you are probably saying, “Yes Matt, we get that … but what’s your point?”

Well a lot of organizations struggle with the concept of balancing the amount of bugs (and technical debt) in the software we address versus the amount of new features and enhancements we add. We often find that stakeholder who is all about the sexy or the cool — looking for that differentiator users want.  As a software delivery team, we are quick to say to the stakeholder, “You don’t get it; users aren’t going to like this and it’s going to cost us more to fix later.” This statement is 100% correct. The stakeholder, who may have a case of “rabbit ears” responding to a big prospect need and he or she may not have visibility or understanding about the extent of the technical debt within the software.

So what do we do about it and how do we find balance?  There are four things I’ve seen work really well:

1. Make all bugs and technical debt part of the backlog. I run into folks who will manage bugs in one system and stories (requirements) in another. They need to be together — remember a bug is a feature; it’s just a negative one. You can write the bug as a story. The bugs should be ranked and treated like any other member of the backlog.

2. Create metrics and make them BIG AND VISIBLE. A chart that demonstrates the number of bugs by severity on a specific day is not too useful to communicate this problem. But, a chart that shows a trend over the last six months, the number of bugs found with a corresponding chart series that shows the number of support calls for the same period, and with another line that shows % of maintenance renewals — well, now you have a powerful story. How about a chart for measuring quality that is based on the number of known bugs released / number of support calls? Or, similarly, the number of new features released / number of support calls. And, how about a simple number — the % of our total backlog that is associated with bugs and technical debt. I guarantee a high number will get someone’s attention. Make these charts part of your team’s information radiator, post them on the wall in the break room, or start making them part of that weekly project report.

3. Conduct frequent Extermination Hack Fests. Establish one day per iteration as a bug extermination day or maybe ever three iterations; use multiple days for this activity. This is not just about having an hardening sprint; it is about allowing the engineers (architects, testers and developers) to team up and knock out bugs with the only consideration that once you start working on a bug, it must be fixed or an approach designed to fix, by the end of the Extermination Period.

4. Align resolving bugs and technical debt with strategic goals. Almost all companies have goals associated with customer satisfaction, or growing our footprint within our existing customer base, or establishing market leadership. These goals are not achieved by putting out crappy product. By leveraging the metrics above, value can be placed and impact measured of resolving bugs and paying back debt to achieve strategic goals. Be sure to measure improvements and investment against the goals as they surrounds bugs, and make it known when the team has an Extermination Hack Fest that resolves 15 customer-found bugs, which will improve our positioning on customers paying ongoing maintenance.

These are the four I’ve seen.  What have you used to get over the tug-of-war between new stuff versus bugs?