If you ever work on code and are afraid to change a part of it because it might break, you’ve got a serious problem on your hands. If you are afraid to change code, that means you’re afraid to improve code. That means you can’t make it better and you can’t add features to it. Living in fear is no way to live.
If someone ever says, “don’t touch it” in regards to code, that means someone screwed up a long time ago and now everyone at the company has to pay the price. The code is holding your productivity hostage. There are so many ways you’d like to improve the code in your project, but your changes keep on getting tangled up with this knot of instability.
This is not the natural order of things. Just because a project lives long enough doesn’t mean that there has to be fragile pieces of code that break if you look at it wrong. It’s just that so much technical debt has added up around the code that someone should have dealt with it a long time ago. Now, nobody wants to deal with it. If you or your company is afraid to change a piece of code, “you’re doing it wrong”. Here’s how you can fix this problem:
Write some high level integration tests around the code to the point where you’re confident enough that they will catch if the code breaks. These tests are going to act as a scaffolding to keep your structure sound. Consider using a tool like Approval Tests. Next, start refactoring so that the code becomes easier to understand. Write some lower level tests that run much faster than the higher level tests that gradually replace them.
Now, if you’ve inherited a huge code base, I don’t recommend going around doing this just because you find an eyesore. You should have a pertinent goal in mind first. Like, if you need to add a feature to a section of code or the “do not touch” code seems to be breaking occasionally, the effort you put into refactoring it will be worth it.
Let me reiterate, you should not be living in fear of your code. It should not feel like you introduce multiple bugs every time you fix one. You should rarely be putting out fires for production environments. If you’re living in this kind of fear, “you’re doing it wrong”. I see a lot of people who have deploys that take days to finish and they need to be on call all throughout the night. This is a sign of poor quality software.
You and your company should be driving towards Continuous Delivery or Continuous Deployment. You should be so confident with your commits that someone could deploy your code without telling you and you wouldn’t be concerned.
This is the opposite of “don’t touch it”. This is the opposite of fear. This is having so much confidence in your code that if someone breaks it, you know an automated test will tell you minutes before someone from QA could test it even if they made it their highest priority. If you write the code, it is your responsibility to maintain it in confidence.