No Pain Guide To Legacy Projects Maintenance
This is the second part of my blog posts series about Legacy projects . In my previous post, I introduced Legacy projects and explained why we should only maintain legacy projects if no new features are added to them [Legacy, isn’t that a good thing ?].
Today I will share a guide on how to easily maintain a legacy project.
It is easy to feel overwhelmed and frustrated when assigned a Legacy project . I would start by keeping those 2 things in mind:
You should own your code: Because working on those projects is tedious they tend to be orphans. The first step in having a well-maintained project is making sure it has a clear owner. I would also advise ignoring the common practice of assigning junior developers to such project and have an experienced developer take responsibility for it. Experienced engineers usually have a better understanding of historical decisions made on the project and thus will have an easier time maintaining it on top of their current project. For the long run, you don’t want to burn out junior developers by assigning frustrating projects to them.
Rome wasn’t built in a day. If you haven’t worked on this project before it will take you a long time to understand everything the project does. You will probably never have to fix most of the project so my suggestion is to skip trying to learn it. Invest time only in the parts you need to fix now.
Now that we established ownership and understood that we will understand the project on-the-go I would like to share with you my rules for successful project maintenance.
4 rules for successfully maintaining a project:
Keep everything under CI. At Wix we do Continuous Integration programming, Deploy to production is easy and is done regularly.
- Make sure the build is always green. Verify you‘re alerted if your project breaks and get it fixed as soon as possible. You don’t have to fix it yourself, maintaining legacy project should be a team effort. You can ask the person who broke the build to fix it or ask your manager to allocate someone to help with this task. But it’s your responsibility to make sure the build is green again.
- Deploy to production regularly. We decided on a policy of no more then a month between deployments. If you haven’t deployed for over a month you will get an automated email to remind you to deploy. If you feel confident enough you can write an automated process to deploy the project and monitor it after the deployment.
Deploying frequently will verify no runtime problems were introduce. It will allow you to quickly troubleshoot if there is a runtime issue (you will only have to go through the changes of the last month).
Keep up to date with dependencies. It is very tempting to freeze dependency versions so you won’t have to deal with breaking changes — Don’t do it. The bigger the gap between versions the more pain you’ll have to upgrade, and you might have to upgrade because of important security changes or API changes.
Most minor versions don’t have breaking changes. If a breaking change was introduced you need to evaluate how much effort is required to fix it: if it’s small then invest the time and do it. If it’s Medium or Large it’s up to you to decide if you want to pay the price now or defer it to a later time (Keep in mind you might be under pressure later).
Quarantine you dead code. If you use internal framework projects you might find that some shared code is used by legacy projects only. This code is polluting those shared projects. It will also be used by new projects even if you mark it as deprecated (Remember: code that exists — will be used).
If only your project uses that code move it to your project. If not, create a new hidden shared project and move the code there.
Small steps are the key. Allocate regular time to dedicate to the project (even an hour per week can make a big change). Improve tests, make small refactors, remove deprecations and dead code.
Remember the boy scout rule: Always keep the campground cleaner
than you found it.
Will it ever end?
That’s a very good question. The thing to remember about legacy projects is that they are typically very profitable: They require very little resources but make the company money.
An end of life can be achieved when :
1. The product doesn’t make money anymore.
2. Customers were migrated to a newer system.
3. The technology the project runs on is no longer supported.
Legacy projects are like your marriage after 10 years. A little maintenance, done regularly, can go a long way
Good luck! My next post will be about rewriting legacy projects
you’re welcome to follow me here or on twitter
