What is it?
Find out more about agile-together here
Over the years, I have heard so many definitions of legacy code.
- Its code without tests?
- Its code without documentation
- Its code without comments
- Its old code
- Its code that requires maintenance
- Its code without useful tests
I prefer the answer: Its all code. There is no such thing as legacy code, it’s all just code.
The problem with the definitions above is they exclude code based on opinion. If we want a definition of legacy code, it must be measurable and quantifiable. That begs the questions, how do we measure legacy code and what are the attributes of legacy code and the most important what actions should we take to address the legacy code?
Developers are obsessed with improving things, tidying things up and making them better. They are world builders, and if the world isn’t how, they want, it can drive them nuts. But they often forget that the enemy of perfect is okay.
So even if your developers have been asking for weeks, months years to refactor what they consider the stain on their masterpiece asks them the following questions?
How much has the code targeted for refactoring cost the company in developer wages in the last 12 months?
How many bugs have been identified and reported in the code in the last 12 months?
How many features have been delayed due to the code in the last 12 months?
These three questions will enable your understanding that while some code is smelly, ugly completely illegible, it may be too cost-effective code.
Being able to measure code from a financial point of view is critical to understand the cost-benefit analysis of refactoring code.
Find out more about agile-together here
