Weighing value of change vs. cost, how to handle costly changes

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.