I mention this problem in my book Street Coder in the section titled "Fix it even if it ain't broken". There's value in changing code, but there's also risk in

I mention this problem in my book Street Coder in the section titled "Fix it even if it ain't broken". There's value in changing code, but there's also risk in doing it. One of my suggestions is that any component that you avoid breaking, deserves to be broken the earliest. The rigidity (the resistance to change and the inclination to break) of code is a sign of greater trouble in the future, so should be addressed the soonest. That means, I don't agree with the "don't fix it if it ain't broken" sentiment fully. If that component's so valuable, it must be covered by hell a lot of test coverage to make it impossible to break it with changes in the first place. If you can break it without knowing, that's a problem that needs to be addressed immediately. I say, break it, identify breaking points, add tests to those points, so the component becomes flexible. My second suggestion is to make the changes, but discarding them after. I also emphasize this in the section titled "Write it from scratch". By doing that, you gain certain level of insight into that rigid design, and improve your understanding of the code base, which eventually leads you to the phase where you can finally code changes that you're comfortable sharing with your colleagues. You may think of the writing code only to throw it away a wasteful exercise, but I argue that it's not as great a loss as you may anticipate.