Techniques to Safely Change Code You Don’t Understand

Picture this: you have a new project, 10.000 lines of code, no documentation, all developers who worked on the project have left the project and you must get a new version out in 3 months. I bet many of you have been in this situation before. I also bet this was a big challenge for the managers, the team leads, the developers and the testers in the team. How do you manage to understand the code well enough to change it without introducing new bugs, in a short time frame and starting from almost no information and a lot of ugly code?

Situation no. 2: You worked on the same project for 1-2 years, the client wants a lot of changes, the code starts to become unreadable. Still the clients expect new features coming at the same pace, and yells at you when a new bug is found. What do you do now?

We have experienced these problems too. We are often called to help teams and developers who work on existing code. In a few days, we need to deliver new features, while increasing the quality of the code. We can only do this because we learned how to safely change existing code, even when we don’t understand it. We learned a lot of techniques, and the time and place to apply them.

So, how do we do it?

First of all we encourage the team to write automated tests, especially for the modules that change a lot. Automated tests help programmers to be certain they changed only the part of the system that should have changed. Testers will be more confident in their work because they have a safety net. In addition, testers have more time to perform exploratory testing in order to uncover extreme cases and strange defects that automated tests missed. The tests run continuously, at each change, on a dedicated server. Each time the tests raise an issue, the team is announced that the build is broken. The automated tests that run at each change should be very fast. Very fast means a couple of seconds up to a couple tens of seconds. Whenever the run time for the tests is longer the team optimizes the tests to make them run faster.

As a tip, it’s better to run only the unit tests on each change, because they provide the fastest feedback. Other types of tests who focus on finding different kinds of issues are implemented in addition. For example: system tests, performance tests, UI tests, etc. These tests are slower and can run during the night.

Secondly we teach the programmers techniques for safely change existing code. We have gathered these techniques in a workshop called Working FAST and safe with existing code, but we also teach them on site as needed. The key point of the techniques is to take very small steps when changing a system. Our experience shows us that typically programmers change too many things at the same time . Taking large steps causes side-effects that often transform into new defects that cost time and money to fix. Taking very small steps is not natural; this is why it’s better for programmers to have a guide who can help them whenever they need. The basic techniques we insist on are:

• do not fix potential bugs because they could be features
• how to add systems tests without introducing defects
• how to encapsulate external dependencies
• how to safely refactor the code logic, extracting new classes when the design needs to be improved.

Using these techniques, not only we learn about the existing code in a way that’s easy to pass on to other developers, but we also add a safety net to the product that helps prevent future mistakes.

As a tip, in order to learn how to take baby steps a local source control system where the programmer can commit often and fast is essential.

The third idea we insist on is the Boy Scout Rule: always leave the code cleaner than how you found it. This rule enables the team to speed-up development in time, with minimal and incremental investment. Making small changes that improve readability and understanding of the code will reduce the time to change the same area of the application later in the project.

These are just some of the techniques we know and teach for safely changing existing code, even when we don’t understand it.

If you are interested in this topic, please contact us and we will be happy to have a chat.