Beware of Technical Projects
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 why code becomes old and very hard to maintain, making it quite a difficult task to keep an organisation’s codebase up to 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 and it became more useful than expected, surviving years running in production, but also with high maintenance 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, and as John once told me:
Any project which starts with a laundry list of tasks 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 maintained 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 maintained for a reason, and if no reason can be found, then it might as well be deleted.