Legacy, Isn’t That A Good Thing?
Non-programmers think being a legacy is a great thing, But for programmers working on a legacy project is one of our darkest fears.
In this series of blog posts I would like to explore why we have such projects and share some approaches to handling them.
Let’s start at the beginning: No project is born as legacy.
All projects start with a good idea. The project is successful, over time it gain customers and new features are added to it. But after a while something happens and we suddenly tag it as legacy.
But what is it that happens? Those are 3 possible options :
1. A shift in technology: We have a great project but the technology it supports became obsolete. A good example is Wix Flash editor.
Wix was founded as a DIY tool for building flash websites. And then the IPhone entered our lives, and it didn’t support flash websites. Suddenly this state of the art technology became old news. The company developed a new editor for building HTML5 websites and this great project was marked as legacy.
2. Badly written projects: This is the classical case we all think of. Projects that weren’t written properly, didn’t have enough tests, weren’t refactored and their code became a spaghetti code that prevents us from adding new features to them.
3. Customer growth drives change: This is the best scenario. We have a properly written project that is so successful that it doesn’t scale anymore. That happened to the Wix Stores project. It was originally written on top of Magento which is an eCommerce solution over PHP. But the scale of our customers grew so much that the framework couldn’t support it anymore and we had to write a new solution and the old solution was marked as legacy project.
All of those projects still have customers but new features are not added to them — thus they are now legacy projects.
How should we handle them?
Now we know why we have them it’s time to discuss what should we do with them. There are 4 options:
- Let me start by clarifying why “Do nothing” -is not an option:
We all know the saying “If it ain’t broke, don’t fix it”. But a project is not an island; it doesn’t run in an isolated environment. An api it calls might change, A library it uses could have a security update, a shared technology like a DB might be upgraded across the company, and you might even find an urgent bug. If you don’t maintain the project, it will become very hard for you to update the project when one of those cases arises. - Rewrite is a developers favorite solution. But rewrite takes a lot of time and resources and not all projects are worth that. In order to make this decision ask yourself the question: Is the project still growing?
If we’re still adding features to the project we need to make it a painless process, Rewriting will pay off in the long run.
I will give tips and ideas for a successful rewrite in my 3rd post: How to rewrite a legacy project and stay alive - Maintenance. If a project has customers but we’re not adding new features to it then we should invest as little time a possible on it, while maintaining it so we can update it at any time.
I will discuss that in detail in my 2nd post: No pain Guide to maintenance of legacy projects - Refactor. The last option is usually a compromise. It’s projects that we know we need to rewrite but we don’t have the resources right now or we think it’s the best ROI . It’s the reality for most of us and I will discuss it in detail in my 4th post: Small steps to refactoring legacy projects
Ready to dive in? Next post I’ll discuss maintaining legacy projects.
You can stay tuned by following me on medium or on twitter
