[robert_tweed]

I think the conclusion here is back-to-front.

Code that never needs to be touched is fine. Although the odds are that such code is either completely trivial or subtly wrong (or both).

Code that is touched every day is likely to be fine as well. It's should get smoothed out naturally, like a pebble in a stream. If not, you probably already have lots of alarm bells telling you it's a problem without the need for any further analysis. It's not the code quality that matters here so much as the test coverage.

The changes you really need to worry about are to code nobody has touched for 3 years and whoever wrote it no longer works for the company. Especially if that code was written with the mindset of "nobody will ever care about this code".

A better metric for deciding where you should focus the most effort on code quality is not frequency of modification, it is frequency of appearance in the runtime call-graph. Each call probably also need a multiplier for how deep in the call-stack it was, since that's where unintended consequences of a small change are likely to have the biggest blast radius.

[geocar]

> A better metric for deciding where you should focus the most effort on code quality is not frequency of modification

Frequency of modification is an excellent predictor though:

https://www.microsoft.com/en-us/research/wp-content/uploads/...

and efforts to get good predictions out of attestations of quality have so far have not been able to make as good predictions as that for sure.

> Code that never needs to be touched is fine. Although the odds are that such code is either completely trivial or subtly wrong (or both).

I'm not convinced of this: I think the longer code lives, the easier it is to convince myself it's probably correct (or at least, correct from the business perspective). Can you explain how you get your odds?

> The changes you really need to worry about are to code nobody has touched for 3 years and whoever wrote it no longer works for the company. Especially if that code was written with the mindset of "nobody will ever care about this code".

I think this is predicated on whether that code needs to be changed at all: You said you think it's likely it will need to be changed, but I don't see why you think that.

[omegalulw]

> A better metric for deciding where you should focus the most effort on code quality is not frequency of modification, it is frequency of appearance in the runtime call-graph.

On th flip side, a lot of code that isn't common in the main codepath often exists to fix edge case bugs that people have lost context on. In my experience, this code is a landmine with an unknown blast radius, only touch it with a 10-foot pole and only when you absolutely must.