Legacy Code: 4 Ways to Keep Your Team Motivated
Legacy code is everywhere. It affects the whole team, and everyone has their part to play in effectively managing it.
Most programmers would try to refactor or rewrite it from scratch but what’s a manager’s point of view? Let’s have a look at 4 things a manager should be aware of;
It’s easy to think that developers don’t like legacy code because they are lazy or to think they’re exaggerating about how bad it is. If the code was written years ago, going through it is like peeling layers off an onion. It’s delicate work which can lead to tears, and it will probably take longer than you expected, thus reducing your team’s performance and productivity. This is why it is essential to be able to measure your amount of technical debt with KPIs and dashboards: you’ll look at the work your team is doing in a more objective way.
Don’t assign legacy handling to a single person as they will possess all the knowledge, causing havoc if they decide to leave the company or even when they go on vacation. Share the knowledge around the team so a single dependency is not present. Furthermore, working with legacy code is not always fun, so you shouldn’t expect someone with only legacy code duties to be happy. Everyone gets frustrated, it’s just a matter of time. Reminding your team how valuable the job they’re doing on legacy code is, will help keep motivation and focus high.
Frustration caused by permanent work on legacy code and the feeling of career stagnation can be better managed if said code can be split into different sub-parts like legacy business logic, legacy data access layer, legacy model / view, and so on. You can then rotate people from one part to another, increasing knowledge sharing and reducing frustration as you go.
A smart manager should manage expectations. Firstly, focus the team’s expectations, because no one really likes working with messy code but if explained in the right way (usually by stressing how important or how strategic it is), most people will accept it. Secondly, all stakeholders must be aware of how risky it is to have messy legacy code. It always ends up costing you more in time and resources, and it’s notorious for hiding bugs. Using tools to display dashboards showing the state of the project, especially relating to technical debt, helps to understand the key challenges and how important it is to address legacy code.
Rather than thinking of legacy code as a technical burden think of it as the foundation of the future software. It needs to be improved and strengthened in order to reduce technical debt and to create a more solid product. Technical debt is the collection of “grey decisions” we make for the sake of meeting deadlines or coding something that “just works”. Metrics are key in the management of legacy code to help the Project Manager make the right calls and will also help you plan and prioritize the effort of refactoring. As a Project Manager, you cannot improve what you don’t measure and what you don’t measure cannot be improved.