Home Home

A bug or a change?

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
June 19, 2016

A feature is delivered to a customer. The customer complains that something doesn't behave as expected and creates a ticket in a bug tracking system. Should we classify this ticket as a bug or a change? The question matters for many software development companies. However, this is mostly a distinction without a difference.

I often see teams complaining that the customer has assigned as a bug something which should have been a change. They'll start rereading—oh, no, sorry, I meant reading for the first time—the spec, and claiming that nothing in the spec allows one to claim that there is a bug: instead, customer changed his mind, making it a feature. The customer will respond that one has to be insane to believe that the actual behavior could make any sense... This can take hours, sometimes days.

In some companies, this distinction is particularly important in terms of SLAs. If it's a bug, the company will have to pay a fine to the customer for every hour spent solving the bug. So now, there is a financial incentive for a customer to claim that everything is a bug, and for a company to claim that nothing is, and there is an incentive for lawyers to spend days drafting the contract to explain what is a bug and what it isn't. All this time could be used to do things which actually matter, such as developing the product or understanding the user's needs.

The distinction makes no sense. If you were asked to deliver something to a customer, and the customer is not happy with the result, there are two possible consequences: either the customer acknowledges your skills and your professionalism and simply claims that the delivered product doesn't fulfill the needs well enough, or he considers that you're unprofessional or a simple scammer. In the first case, he'll pay extra to change the product; in the second case, he'll sue you or simply throw your work away and go look for somebody else to create the product.

Agile embraces this approach quite well. Each iteration makes it possible for the customer to readjust the product: this means both change his mind about the different aspects of the product, and specify some aspects which weren't specified well enough or understood correctly by developers. The changes in both cases can actually be minimized with prototyping and better communication. Shorter iterations help too.

Does it mean that bugs per se don't exist? Of course not, and the distinction that Joel Spolsky makes in the fifth point of Joel test makes perfect sense. For those of you who don't remember the exact formulation, here it is:

5. Do you fix bugs before writing new code?

[...] In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix. [...]

Source: Joel test

It has absolutely nothing to do about the distinction between a bug and a change a customer may make in a bug tracking system after he receives a new feature. Instead, Joel talks specifically about issues which could have been solved in the early stages—much before the actual delivery of the feature, and compares them to adding new features. That is a useful distinction, which not only makes sense, but is very useful: by solving issues first, before bloating the product with new features, one can decrease considerably the cost of solving the issues in the first place.

Unfortunately, I've seen some companies use Joel test while completely misunderstanding it. They would create a distinction among customer-opened tickets between bugs and changes, and make bugs higher priority, or put strict SLAs. And that not only is harmful, but could often lead to crazy situations. Let me illustrate that.

Imagine that a customer requested to develop a feature. By mistake, he explained a given aspect of it wrongly; since it was written in the spec and confirmed by the customer, there are no doubts on that. Now, the feature was also delivered with a few minor bugs, mostly cosmetic, but which take at least a whole week to solve: they are undoubtedly bugs, since the requirements clearly specify how things should have been done. With SLAs, those bugs will have a higher priority, independently of their relative irrelevancy for the customer. No matter how blocking for the customer's business is to have the feature changed as fast as possible, developers will spend a week fixing the pseudo-bugs before starting to work on the new, amended requirements.

In practice, this situation happens on regular basis. When I worked as a project manager in one multinational company, it was amazing to see how many situations there were when the customer couldn't prioritize the tasks properly, because of the SLAs the same customer insisted to set up. Everyone was unhappy, but SLAs remained, and was never even questioned, because that's the way it always worked.