I have written about small changes and big refactorings in legacy code. But before one starts changing everything in a legacy code base there is one important hurdle to take: The rest of the team has to agree with you making those changes or even better, they should be part of this.

Overcoming the Inertia of Habit

If you look at old, rusty, ineffective and hardly maintainable code, it may be clear for any outsider that it needs improvement and therefore changing. However, if the code really is that old, that means that the people on the team have been working with that rust and clumsiness for several years.

People who have worked on a legacy code base for several years can be partitioned into different camps. For once, there will be people who always wanted to change how things are and improve the code. The other camp are people who got used to how things are and feel at home in the muddy pile that is their code base.

Different people have to be addressed differently. So the first thing to find out about the team is which camp they belong to, if they can be your allies or if they need some convincing in your quest to improve the world – erm, the code base.

Finding Support

Depending on the code size and how badly it needs an overhaul, your quest can be quite a daunting task. While the whole team might benefit from it on the long run, it usually requires some investment. Team leaders and other decision makers need to be convinced, so it is better if you are not the only one in the team speaking up.

Teammates that support your cause can be found easiest in the first group I mentioned above, those who already are in favor of improving the code base. If there has not been an attempt to improve it already, that means those people are either a minority or they have excuses “like there was never time to do those things” or “we don’t know how and where to start”.

The point to those excuses is that they really are only excuses. Once the team and decision makers are convinced that the code needs some major improvement, there usually is a way to make the time necessary and find a way how to start. For starters it is enough to get them to openly say that you’re not the only one who thinks that improvement is needed.

Convincing the Rest of the Team

Once you have gotten the first group of supporters on your side, it is time to convince the harder cases. Sometimes they just need an eye-opener, some compelling argument why things don’t have to be the way they are.

Such arguments can be for example easier or faster development. People who have been buried in the same code base for years sometimes don’t remember how things can be different to what they are used to now. For example, you could tell them, that it is not normal for unit tests to run for an hour, or that they don’t need to try and catch wherever an exception might occur.

Convincing the Boss

Obviously, convincing the decision makers of the necessity of the improvements is a crucial part that can make or break the whole thing. Usually the only way to convince them is to show that it is worth the time and money spent.

You should be able to quantify the improvements, in less time spent during development and testing, or in a reduced risk of having hidden bugs in the program and so on. That means you should know the program and the code base sufficiently well.

It is best to have the whole team back you up on this, so have some brainstorming together what can be done, how it can be done and what measurable improvements will come out of it in the end. In addition, decision makers are more easily convinced if the team comes to them and asks for those investments, than if a single person is asking, who is relatively new on the team.

Make it a Team Project

Having the team backing you up on the desire to improve the code base is nice. However, you will get real commitment only if they are involved in the process. If they are part of it that means it is no longer “your little experiment” in their heads, but a team project.

If your plan (the teams plan, that is) is a huge refactoring, you will need them anyways, because it is better to have a few weeks of only technical tasks instead of a long term construction site all over the code during ongoing functional maintenance.

If the changes are smaller, there still are some ways to give them some participation. Give a small presentation on the changes you have made. Have them review and test your code. Make them use it and adopt it as something that belongs to the code base now.

Conclusion

This blog post has been less about coding and more about soft skills, especially communication. But that’s OK, because soft skills are essential for successfully writing software. You usually don’t work alone on a software project, and after all, we write readable source code to communicate with other developers, not with a CPU which understands only 1s and 0s.