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?

Are you in a position of sufficient authority to make those kinds of decisions? — Robert Harvey, Mar 25 '16 at 21:19
Not clear on the relevance of your question Robert, since the question seems to stand the same either way? — Bradley Thomas, Mar 25 '16 at 21:22
If you don't have the authority, your question is... not exactly irrelevant, but clearly immaterial. — Robert Harvey, Mar 25 '16 at 21:24
Possible duplicate of [How can I convince management to deal with technical debt?](http://programmers.stackexchange.com/questions/43948/how-can-i-convince-management-to-deal-with-technical-debt) — Robert Harvey, Mar 25 '16 at 21:26
Some guide on when to refactor and when to rewrite: http://programmers.stackexchange.com/a/161912/61852 — Tulains Córdova, Mar 25 '16 at 21:53
[PEF/REV](http://programmers.stackexchange.com/a/207090/34608) might be useful to get everyone talking the same language — AakashM, Apr 07 '16 at 12:17

ptyx · Accepted Answer · 2016-03-25T21:28:34.907

4

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.

edited Mar 25 '16 at 21:28

answered Mar 25 '16 at 21:22

ptyx

5,851
2
22
21

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. – Frank Hileman Mar 25 '16 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 '16 at 21:28

score 1 · Answer 2 · answered Apr 07 '16 at 10:53

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.

score 1 · Answer 3 · answered Apr 07 '16 at 11:30

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.

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

3 Answers3