A while back I wrote a little about bugs. I got a few questions and objections and the most common one goes something like this:

"Fixing all the bugs is silly. You're telling me that when somebody reports that IE4 and Netscape Navigator don't properly render your CSS3 transitions, you go in and fix it? Many bugs aren't worth the cost to fix them."

I'm exaggerating, but only slightly. Generally people point out obscure miniscule errors as a way to say my argument is invalid. My answer to the above is simple: that's not a bug. Nobody would reasonably expect that scenario to work, and if it is really necessary it's a user story and should be treated as such. The follow up question to this is naturally...

What Is A Bug?

My comprehensive definition of a a bug is:

A defect is a part of the system that does not work as specified, or a part of the system that while unspecified behaves egregiously (i.e. it crashes).

That sounds professional enough but doesn't really help the situation. I prefer this definition:

A defect is when a developer makes a mistake.

That's a lot better, even though it's less comprehensive and would make a lawyer puke. The important terms to remember here are "developer" and "mistake." Business Analyst specifies the wrong feature? Write a new User Story to change the feature. Nobody likes the new feature? New User Story. If the system doesn't work on IE4 and it needs to, well then you should probably write a story. Let's go through a few examples of potential bug reports, and see if they are really bugs or not.

When I generate a PDF it takes 40 seconds to generate. Fix.

When it comes to the bug or story question, performance and scaling is one of the trickiest areas to make that decision. When determining whether or not a performance issue is a defect you have to ask a few questions:

Was a minimum performance specified?

If we have a system that generates PDFs, like the bug report above, did we originally specify a maximum time limit? If we did then this is probably a bug. Even then we may need to evaluate if the time limit is still reasonable, as we may have added a lot of features to the PDF generation causing it to slow down. We may even be able to throw hardware at it. Still, if we specified a minimum performance and are not meeting it, then it's probably a bug.

Is the performance embarassingly slow?

I keep using emotional terms instead of precise ones, because I usually know in my gut when I've screwed up. Imagine you changed the PDF system above and instead of the bug report saying 40 seconds, it said 2 minutes, or 2 hours. At some point it becomes clear, regardless of specification, that the system is way too slow. Think of links that take 10 seconds, video games that run at 4 frames a second, or iPhone apps that take 2 minutes to start. Context matters, but we don't want to force our customer to write on each feature "and it should be fast enough that the user doesn't think it crashed." Obvious bugs are obvious.

Did it drastically regress?

If the performance was unspecified and is within reasonable parameters, then did it suddenly and drastically regress? Forty seconds may have seemed fine in isolation, but not if it used to take 3. If it did, then we need to look into the reasons why. Perhaps this slowdown was expected, or perhaps it was an accident. Did you add new features and cause a natural slow down? Or did you screw up? That's the difference between a feature and a bug.

On Mobile Safari the popup dialogs don't work

This is a variation on the IE4 bug I described earlier, but one that somebody might reasonably report. The first question to ask is, "Was it specified?" If not, then we ask "Is it reasonable for it to work?" For instance many of the JQuery-UI widgets don't work on Mobile Safari. If you've got an application that's existed for a long time and has many of these dialogs, then it might be a series of stories to optimize the behavior on mobile browsers.

On the other hand if you started the application three months ago and it's been made clear that mobile browsers are a target platform, then hell yes this is a bug. As the developer you should have ensured your code would work across browsers. You made a mistake.

The New File wizard takes too many clicks to get through.

In an Agile approach we refine our solutions over time. We get the first version of an application shipped quickly and get customer feedback as soon as possible, then use that feedback to improve the product. This is closer to what Ward Cunningham meant when he coined the term Technical Debt. We ship code with limited knowledge, and frequently that limited knowledge manifests itself in phrases like: "Well it does the job, but I don't like it."

It is to be expected that no matter how much effort and preparation you put into your user story, even after writing passing acceptance tests, sometimes the completed story will be what the customer said but not what the customer wanted.

This is not a bug. You're refining an existing story based on new information, and should do so in the context of your existing process. Frequently these types of discussions get contentious because the customer, and even other developers in the room, feel like it's a bug. Under pressure to get the stories done right the first time we forget that iterations provide a mechanism for improving existing features, and refining previously played user stories.

There are two ways to help defuse this situation. The first is to remind the customer that they can create more User Stories to improve a feature when there isn't pressure. Sometimes a customer will see something demoed and accept it, but you can just tell it's less than thrilling. Start asking questions about what's wrong, encourage them to write more stories. Remind them that software is never really finished.

The second is to do little things without stories. If the color is wrong, or an icon in the wrong place, just change it right after the meeting. This reminds the customer that your relationship isn't adversarial, and doesn't really hurt you as a developer. They'll see that when you argue against something being a bug you aren't standing on ceremony, but trying build the best software you know how.

All bugs must die, all the time

Pete McBreen wrote: "A Software Craftsman ships with no known defects." This scares a lot of developers, who are concerned that they'll spend all their time gold-plating and never ship, but I believe it's a fundamental idea. It is immoral to know something is broken and ship it anyway. That doesn't mean my software is perfect. It means that I do not knowingly cause problems for users.

We don't accept anything less from other industries. Why should software be any different?