Quite often there are situations where a bug exists in code, or a feature is requested, where it is expected that the fix/implementation will add less value to the business than the cost of any of: implementation, in particular validating that no side-effects are introduced pre-release and implementing any re-work required, OR cost of living with those side-effects in production.

So no-one wants negative ROI, so is it simply the case that we should live with such bugs or absence of desired business features or is there a better way? Is our only rational option to wait to implement these stories, until such a large change is required that they almost resolve themselves naturally as part of a bigger overhaul?

Edit: I am not looking to find a way to convince management to deal with technical debt and relations with management are not part of my question. My question is simply, is there a better option than the choices of (a) negative ROI given the codebase as-is (which may or may not include technical debt) or (b) wait until larger changes to code-base are required?


3 Answers 3


With finite resources, bug fixes should be prioritized the same than any other work (feature requests, performance enhancements, UX improvements, new platforms....).

Don't underestimate the impact of poor quality on your users, or of technical debt on your overall velocity. But realistically, some fixes aren't worth the engineering effort - or not worth diverting resources from that brand new feature everyone is working on.

  • Nice answer. The only thing I would add is that accumulating bugs can make it harder to fix bugs or add features in the future, since they may compound each other, especially when testing. Mar 25, 2016 at 21:26
  • @Frank agreed and answer improved - costly bugs tend to be costly because they're associated to technical debt - and fixing technical debt has its own ROI long term.
    – ptyx
    Mar 25, 2016 at 21:28

Bugs that don't add as much value to the code base as fixing them costs should not be addressed, until there is a time where capable pesonnel in the organization has nothing other to do. (Admit it, you know this happens.)

Since programmers typically draw a salary, this turns the negative ROI into a positive one: the fix still costs more in programmer time than it repays, but is not quite as big a loss as if you'd simply sat around doing nothing.


When do you call a plumber?

  • When your tap starts to drip? Probably not.
  • When your sink starts to block up? Maybe.
  • When that tap washer gives out and mains pressure water deluges into the [blocked up] sink and floods your kitchen out? Too late.

Unfixed bugs have a nasty habit of coming back to haunt you if left for any length of time. Since most will be introduced as part of a development, the best time to fix them is while they're still fresh in the mind of the team/ person that introduced them. Once it's left to sit for a while, nobody will remember anything about that piece of code, which only increases both the cost and the risk of trying to fix it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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