Every release, our trail of bugs keeps on increasing. These are valid bugs however, we also have to write new features to stay in the competition. Also, those features will be more used than the bugfixes; and provide better ROI.

How are other engineers and product owners handling this situation?

  • 8
    Do you know why the number of bugs keeps increasing? – Timo Geusch Jan 19 '12 at 2:26
  • as Timo Geush mentioned, do you know the reason for the increase in bugs? From your question it seems that your priority is to add features with fixing bugs coming secondhand. If you no time, for now, to fix old bugs do everything you can to prevent new bugs from being added. – Filip Jan 19 '12 at 2:47
  • Thanks Timo, Filip. I glanced our some bugs and I found that we compare ROI from the bug and a feature which can be done in same time. and we ask questions: e.g., is there a workaround? Having said that, this discussion has reinforced some good patterns in my brain. – Asad Iqbal Jan 25 '12 at 9:27

At a technical level, bugs, features, it's all the same, a change request. Do you ever decide not to add a feature because it's not worth it? It's the same with bugs. The only difference between bugs and features is commercial - 'customers' pay for features, the 'company' pays for bug fixes, or something like that.

However, as with feature requests, every bug report needs a change tracking ticket. The ticket must be as easy to close as it is to open. That is the only way you will capture the data you need to make decisions.

Change requests should be closed as quickly as possible. The reason for this is open requests take time to analyze, clog up the system and add little value. You need to quick way to decide that you won't do it, and once that decision is made, close the ticket. You should aim to never discuss if an item should be open or closed more than once. One of the biggest problems I see it the reluctance of people to close a ticket "Will not fix", so they leave it open. If you ain't gong to fix it, be honest to everyone and just say "We ain't going to fix that, get over it."

Have both Priority and Severity in your ticket. The effect of the defect on the system is it's severity, sales and marketing set the priority.

Other tips: Use a figure (say 20%) from the budget of feature requests/enhancements for fixing bugs. (i.e. if I do 10 days adding features, I do 2 days fixing bugs). Bugs are fixed in Priority order till the budget is spent. This gets around the commercial drive for features only development.

The cost of a defect is exponentially proportional to the time between insertion of the defect and fix (Or decision not to fix) of that defect. To prevent those niggle bugs costing disproportionate amounts of $ because you don't fix them, and refuse to close them, open tickets have their priority raised on a regular basis (Say 5 priority levels - once a month), and cannot be lowered. That way, you will be forced to deal with it within say 6-12 months.

  • The problem is business is fluid, not static. The overall strategy and goals may change causing changes in priorities. Defects that were low priority may become higher priority. However, if they are all closed you won't know if they were actually fixed or not. I don't want to confuse fixed defects with defects that were closed and not fixed. – dietbuddha Jan 19 '12 at 23:28
  • My point is refusal to close defects where the developer has nether the resources , desire or intention of fixing is common and ultimately expensive. Every time you have a review meeting, it must be revisited (or you are only doing half the job), each meeting takes longer than the last and the reports get polluted with historic data. Reports on "Closed + Will Not Fix" can then be used where required, and an issue can always be reopened if you change your mind about it. – mattnz Jan 20 '12 at 0:08

You should have a triage and priorities meeting on a regular basis.

At my previous job we used to have a weekly meeting that consisted of product owners and the dev lead (me). We would

  • review current priorites
  • prioritize new bugs
  • prioritize new features

The goal was to make sure there was a balance in what we worked on. I would explain the cost of ignoring certain problems and how much they would cost down the line. I would also explain the development cost for each change and offer up alternatives when appropriate. In return I would get a sense of the importance of certain features to the business. This provided both myself and the product managers with

  • a good idea of how resources were being spent
  • consensus on how to utilize the resources we have
  • a deeper understanding of the business as a whole

Once a rapport had been established, the meetings went by quickly with few disagreements.

  • good answer, although, I don't know if most devs can meet with product owners.. – Jake Berger Jan 19 '12 at 15:35
  • @jberger: It has to happen at some level. Either at a higher level with VPs meeting together or a lower level like a dev lead meeting with a product manager. The problem is without that communication you CANNOT correctly prioritize work based on importance and impact to the business. – dietbuddha Jan 19 '12 at 23:17
  • definitely. however, some business environments don't encourage this type of customer-to-software team relationship. in fact, ours is almost the opposite. some big customer wants a feature, we create it and they will only ever call back if there's a bug that brings down there entire "system". – Jake Berger Jan 20 '12 at 15:36

Keep a database with all the bugs and bug reports and deal with them when new features stop being as relevant, while trying to focus the bugs that happen most often and with the most impact on the program.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.