> In my experience no coding standards or cleanliness can prevent this. The only sure way is testing on commit/PR.

I think that's an issue with how people define "clean." It isn't just about surface aesthetics. Think of a cooking appliance that looks "clean" in its design, that might win a designy design award, but accumulates gunk in hard-to-reach crevices because it was only designed to look clean, not designed to be kept actually clean.

Fair enough - it may be that I've never experienced "real" clean code. But I've worked with many good engineers and seen this problem repeatedly. However, no matter how unclean the code is a rigorous test suite will find many regressions.

A modular architecture will prevent changes to one system from breaking other systems.

hard disagree, there are definitely ways to prevent this, it's a matter of do developers even consider it?

No, they don't. But that's the problem, you can't force all developers to consider these issues and adhere to coding standards. Sure, you can do reviews and then make them do that, but if they have to pass a suite of tests before it even gets to review then that's going to save everyone's time and train them to do it right.

Coding standards an cleanliness are at the wrong level.

What makes it easy to make changes, add features, find bugs, etc. is good design.

Testing can help find problems, sure, but you can't test in quality (you can only, to a degree, test in robustness).

The difference between a decent design and a mess is mostly what happens when your "simple, local fix" causes unexpected tests to fail. If your first reaction is "damn, guess we can't do that" three is a good chance you have a mess on your hands.

Clean code (yes some of this is just taste) is mostly a symptom that people have been thinking about this stuff, not a guarantee.

There is a corollary though, which is difficult. Quality of design and techniques used mostly put an upper bound on the complexity the system can have before it becomes unmanageable. If it grows long enough though, it will get there.

> A common failure mode I've noticed is that people only test the functionality they've added and not other parts of the system that may be affected.

This failure mode often comes from parts of the system being coupled when they shouldn't be, or it's not obvious that they are.

Have you ever had a change to a logging statement break cause some other code to stop functioning? I have. And I was thoroughly disappointed by the person who made a logging statement have any effect outside of logging.

Clean code needs to adhere to principles such as the Principle of Least Astonishment[0], otherwise code is bound to break when other people modify it.

[0] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

About "Principle of Least Astonishment": In theory, it is cool. In practice, it is often used by gate keepers to shutdown newbies. After seeing that behaviour too many times, I stopped using the term.

A nicer way to say it (from pair programming ethos): If someone asks you a question to clarify some code, then it needs a comment (or a re-write/re-factor). Note that I didn't say anything about the experience level of the asker.

One more thing: I've met (multiple) people who are firmly in the "Convention over configuration" camp and the "Principle of Least Astonishment" camp and cannot understand how new joiners are continuously surprised by this or that convention.