To Fix or Not to Fix : That is the Question

Dave Churchville talks about things you should care about when planning bug fixes. I totally agree with his point. On one hand, it does not make sense to implement more and more features without fixing serious hazards first. This is sometimes called creeping featuritis. On the other hand, stopping any shipping till every bug is fixed can make more harm than good : a buggy software can provide more value to the user than no software at all.
I must confess that I had not fully understood the arguments in his first post. Indeed, one of the biggest misconception in software development is that bugs don't need to be prioritized just like any other feature.
That being said, it is a wise decision to let the business, the customer or the product owner, decide if the development team should implement new features or fix a few more bugs. Now the problem is : does the business have enough information to make a good decision ?
The person, or group of persons, making the decision must:

  1. be aware of the final user needs at a fine level of details

  2. know the technical impacts of an issue whether it is fixed or not

Regarding #1, one could tell that it's the business people job to make decision regarding actual user needs. Things are not so simple.
If we are talking about in-house software development and the final users are a group of people working at the next floor, they are probably involved in the decision process, or, at least, someone will ask them when a decision on a tricky issue is needed.
If we are talking about a software shop and the final users are people working in other companies, things are getting touchy. In this case, the product owner probably has a customer's business background but she might not have the knowledge required by every position in this business. It is ok when prioritizing features at a coarse level but it can turn into dice rolling when dealing with detailed activity of a real user.

Listing #2 as a pre-requisite for business people might look counter intuitive : why should we care about technical details when deciding on which bug or feature the development team should work on ? The answer lies in the nature of a bug.
When a feature is not implemented, there are no side effects. One can find a workaround to fulfill the same needs but does not get unexpected behaviour.
When a bug is not fixed, it is a different story. The bug might be hidden in a lower layer of the software. From there it can have impacts on many features of the application. These "other" bugs were not discovered (yet). It is just a matter of test coverage. Of course, we could just do "more tests" but then the economic argument (do not spend time on fixing bugs because time is money) is no longer valid. Things turn into an arbitration between spending time on tests/spending time on bug fixes/spending time on new features...

I have no answer for these two items but I know for sure that letting the business people unilaterally making the fix/not fix decisions is as bad as letting the developers or the QA people making these decisions. At some point, all these people have to talk to each other to find an agreement regarding the prioritization of bug fixes.
Laurent B.
Je me permet de proposer un lien en rapport à ce billet instructif:
I think such decision must be an agreement between customers and team, but with sufficient data to make the decision.

For example, team may says customers : "This bug is critical and may impact further functionnalities, but it will need quite a lot of time to fix". In such a cas, the product owner has the elements to take the decision.

Another case is "This bug makes this functionnality uncompleted, and it will cost an average time to fix". In this case, the product owner may consider this functionnality is not important and the bug may be fixed later.

I think like any blocking case in an Agile projet, the main idea is that the team gives its technical view, the product owner has its business view, and then he takes its decision. In this way, we consider both technical and business constraints.

Fil des commentaires de ce billet

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.