When to change the code?

Changes aren't free. They're low cost, but not free. Changes are also risky, any change can cause an outage. Many places require code review for every change, so it's not just your time you're choosing to spend.

I apply two rules and a judgement call. I make a change when:

1. It moves us towards a new customer feature.
2. It fixes a customer-relevant bug, including security problems.
3. It will improve our long term delivery rate enough to pay off the investment.

These only work if the team has “worthwhile” projects with "sensible" prioritisation That is it will eventually have a big enough return on invested capital (RoIC). If your project won’t ever pay for itself, directly or otherwise, you have bigger problems.

Big performance fixes can fall under <1>. Your economics are part of the customer experience. Services with negative RoIC attract management’s axe, then customers lose the service. Alternatively, you could make the service cheaper and pass on the savings to the customer. If you do not pass on the savings, will your competitors?

You can mostly-solve <2> with a CI/CD tool that automatically builds, tests, and deploys the service with new dependency security fixes. That way your service mostly runs itself, other than regular dashboard reviews. That said, such a system is an up-front cost, so you need to do the same “is this worth it” check.

<3> is the judgement call and by far the most dangerous. You need a reasonable estimate of your future delivery rate with and without the change. It's bounded by outside forces, e.g. if you aren’t going to build many more features then, you should consider not making code changes.

If I’m not acting under <1> or <2>, I avoid changes like "polish blah" or "refactor widget". It’s too easy to over-state the benefits and under-estimate the costs. They're also more likely to cause churn in the code review as they invoke taste or style more frequently. If I am going to do work on the basis of <3>, I try to make a quick fermi-estimate in my head, and so far that’s been worthwhile for avoiding obviously low or negative RoIC work.

That's it. Spend your time on customer-relevant work with decent RoIC.

Thanks to Alex Willmer, arcatan, hyperpape, kejadlen, and sedatesnail on the Overthinking Everything Discord for their feedback on an earlier draft.