After working in IT for a while, one thing I’ve noticed is that there is a lot of legacy code hanging around. Some companies are better than others in dealing with it, but there are a lot of reasons while code becomes old and very hard to maintain (some discussed here), making it quite a difficult task to keep an organisations’ codebase up do date.
Since every problem must have a solution, legacy code comes hand in hand with “technical” projects, where the main goal is to rewrite an application (or part of it) in a new technology, or in a “better” way.
There are different reasons for this. Sometimes the company traditionally developed things in a specific technology and has since evolved, leaving behind a few systems that were never updated. Sometimes the original code was developed without long term aspirations (some would say hacked together) and it became more useful than expected, surviving years running in production, but also with high maintanance costs and lacking in efficiency.
Just making it clear, I agree with the need of retiring legacy code. I do believe it’s better not to create it in the first place, but once it’s there, something has to be done. However, these kind of projects come with more risks than usual in my opinion, and as John once told me,
“any project thas starts with a laundry list of problems is not a good project”.
First of all, how can you tell what has to be delivered? If something got to the point of being called legacy code, you can be sure it has stayed a few months (or years!) without being properly mantained and evolved. In the current times, any customer needs that were being solved a few years ago are most likely not current anymore. In other words, if you are rewriting the same thing again you are definitely writing the wrong thing.
Besides the business issues, any legacy code that has been around in an organisation for a decent amount of time has lived in the imagination of most developers long enough for everyone to be sure they know what needs for it to be developed perfectly this time. And as in any technical solution that has no customer goals at the end, teams end up spinning their wheels and polishing the codebase over and over again, until they reach perfection or the money runs out (which, sadly, usually happens first).
But how to approach this by not focusing on the problems to be solved? Go back to the origin and find out what problem you are trying to solve. Then find the customers who care about it and start from there. There is nothing different from any other customer facing project organisations deliver.
Every line of code should exist and be mantained for a reason, and if no reason can be found, then it might as well be deleted.