If it’s not broken, don’t fix it?

This is the common saying I heard a lot when I started worked for a software company on development. I can list some of the pros and cons of fix it.

Architecture chaos: if not fixing it, basically as the software ages, per the “broken windows” theory, people would just throw in changes to get things done, without carefully thinking about the architecture, dependencies. And this leads to the related problem below.

Code hard to maintain: it will become harder and harder to fix bugs, or add new features with the code in a messy state.

Introduce new bugs by accident. Or the fix making the software worse. While it’s unlikely, it’s still possible. Not carefully planned fix could introduce bugs, and make the software worse. I have done my share of that too 🙁

If we were to work on the clean up, refactor the code, as a minimum we should have the regression test suites. Or in ideal world, we would have automated unit tests, which could help both speed up development, and give another level of confidence for the code change.