The problem is of course that you may then be changing code which has been field-tested for a long time.

I agree but also think it's worth acknowledging the trade off you're making. If you never touch a piece of code, then at some point nobody remembers or is able to understand what it's doing.

I think this is worse than changing code that has been field tested but admit I am biased because I work on a large project where we are beginning to run into this problem.

As long as the process had been that the only way to get a pull request for a bugfix accepted is by proving the bugfix worked with an automated regression test, then you can change the code as much as you want...

Tests lock you down to particular design by way of the interface. If you want to fundamentally redesign something, you're likely going to have to change the tests as well.

The power of automated testing is really to ensure that nothing changes, which is great when doing bug fixes, but not so great for actually evolving software.

Ultimately it just becomes easier to add new code than it is to ever change a design that is already in place.

Sounds like you are writing tests at the wrong level then.

I was talking about a regression test for a fix for a bug found in production. For a typical backend, write such tests against the publicly exposed API.

If you end up breaking tests as you refactor it means that you have broken backwards compatability for others who use the API...

We seem to be talking at cross-purposes here. I agree that tests enforce backwards compatibility (or compatibility in general) but they also enforce a particular design. Fundamentally redesigning something generally involves breaking the testa and the API.

To put it another way, if you never break your tests you can only ever fix bugs or add more code -- you can never remove code or redesign.

This assumes that if you rewrite a piece of code then the possible bugs in the new code are similar to the bugs in the old code. And that is in general not true.

This seems to be industry and not developer driven, business thinks it's like building a bridge and the manpower (and money) is only needed at the build stage, not the maintenance stage. After it is built money can only be directed into adding features and fixing bugs, not to improving code. This applies at both the macro (project/product) and micro (class, module) level.

We've got a weird situation where the best (best potential) devs are not financially incentivized to reach that potential, the money is in being a locust, showing up, devouring all local resources and then moving on to the next green field.