JoshSweeney

Bugs vs. Features, A Holy War

For anyone who has worked in a software company the bugs vs. features debate is one for the record books. There are always two sides, one that wants more bugs fixed than features added and one that wants the opposite. Both of which are compassionate about the reasons that their views are correct and the others are not. In the end, each side gets a little of what they want and each side feels like they are getting the short end of the stick.

To fully understand this argument lets take a look at both sides of the argument and the factors that come into play. Below I have listed a few arguments from each side. This is in no way a comprehensive list so if you have more suggestions then please comment.

The Bug Squashers:

1. Bugs are costing us deals.

2. The product is unstable which makes us look bad.

3. Bugs expose an underlying engineering issue.

4. More features means more bugs.

The Feature Zealots:

1. Features are costing us deals.

2. We have to weigh time to market.

3. Customer X wants it.

4. We promised it to get the deal.

As you can see, like any holy war each side has valid arguments as to why they are right or, in this case, why they should utilize more engineering time than the other. Fortunately with this war there are solutions to the problem.

Even though we see what the issue is I still don’t beleive that we have gotten to the core. The core reason that people arugue for one or the other because they don’t have the data. Each side sees things one way and thinks that the product manager just doesn’t understand.

If each side was given quantifiable data to backup the decisions made by product management then at least all parties would understand why the decision was made. Everyone who was feeling wronged would now know that the product manager analyzed quantifiable data and came up with a features to bugs ratio that determined the allotted hours spent for each in a span of time.

If you are a product manager you may be saying “why do I have to justify my decision to you.” The answer is that you don’t. However, for coworkers to really believe in your decisions they need to be able to see justification for the for the outline laid before them. The fact that there is quantifiable data backing up the decision makes it where coworkers no longer feel that bug to feature ratios are simply pulled out of the air or are related to to the most angry customer of the day.

Now that we have looked at one of if not the true cause of the issue we need to determine how to quantify the data. For every software company this approach will be different. I will give an outline on a possible solution using one of the common arguments above.

1. Bug or Feature costs us the deal – This is perhaps the most quantifiable argument. By having salespeople utilizing a CRM system or other tracking system, management can impose required fields. I dub these the “Why did we lose the deal fields.” Each of these will be mandatory if a deal is moved to a loss status. Some examples are as follows:

a. Lossed Because: Bug, Feature, Price, etc..

b. If a bug or feature is chosen then which bug or feature. This would need to be a drop down will all product sections or top X number of features requested.

With information about why each deal was lossed and what the sales person sees as the reason, we can now start to quantify the information. We can now run reports on losses and generate a bug to feature ratio. This is quite simplistic but gets us started. In addition to the hard numbers we can factor in the amount lossed on the opportunity/deal. This step will take a more effort mainly because if hinges on the fact that the opportunity numbers are not inflated.

This in no way is a comprehensive solution but gets us on the road to quantifying why we make the decisions that we make.

There is a good number of books that discuss the benefits of quantificaiton and give compelling reasons on why it makes people more satisfied with decisions and companies more profitable. I have personally read Competing on Analytics which also references Moneyball. Information form both of these books is highly recommended when adding in the trials of running or working in a company.

I will end this post with a quote from Lord Kelvin that I beleive should be on the office wall of all decision makers.

“If you can measure that of which you speak, and can express it by a number, you know something of your subject; but if you cannot measure it, your knowledge is meager and unsatisfactory.” Lord Kelvin (William Thomson, 1824-1907)

Tags: bugs, features, product management