In the past I've come across many codebases where there is a daunting uncertainty in the air when you want to make changes or fix anything. Inevitably I'd push subtle issues that may not be caught until too late.

More recently I've had the pleasure of working on a microservice for a client with a budget that allowed for proper coding principles to be exercised, including a decent test pyramid. Common knowledge says that tests make your code easier to work with. Of course there is overhead at the start to write tests, but once you get to the point where you want to refactor any code, that overhead saves so much time. I feel very confident when making changes against a well-tested codebase. I'm never stuck thinking—which costs time—about corner cases or how something might not work as I expect.

This post isn't about the direct value of writing tests though; I wanted to emphasize the value of change.

When something is done a certain way for a prolonged period of time, change is hard. This is a universal issue. But when you do go through with changes and deal with the issues thereafter, it gets easier.

Some test cases might be a pain to update, some might be too brittle, but that is not as obvious before you made the changes. Now that you've gained new insight from the changes, you can make improvements. Brittle or problematic test cases are highlighted by change and can be made more resilient or future-proof. Other existing tests that aren't clear can be updated with better documentation or error messages to enhance spec clarity. Processes and workflows can be refined. All of this thoughtful work is brought about by change. Then, any work in the future gets easier. You can deprecate code easier, update libraries, implement new features, etc., all with high confidence that you are not going to break anything.

Most books will emphasize the value of testing. When you have a decent test suite, change is easier. It's worth it to study about effective test methods. However, I wanted to instead emphasize the value of change here. Change identifies weaknesses. The same way that when you flex or damage some thing, it reveals otherwise invisible flaws about the thing that could be made more resilient. Then, when you fix it (or remake it), it becomes stronger.

Change is a magic. Whenever you're stuck second-guessing if something will work or not after changes, I say just go ahead and find out. If it breaks, it wasn't resilient enough to begin with, and now you can improve it. If something is otherwise brittle, it will be broken eventually. Better to be broken by an expert.