Survival Guide: How To Work With Legacy Systems

Wednesday, June 3, 2009 3:00 AM

By Serhiy Yevtushenko

Almost any software professional, if asked, would prefer to work on the new, green field project. And likewise if asked, on which project they would prefer not to work on, they would answer: old, fragile, big legacy system.
Nevertheless, there are a lot of such systems in the world, and they still bring business value. And while system is being used, it will need to be changed, and there will be a demand for the maintenance of such systems. Especially in current times of crisis.

So, what is a legacy system? Plainly speaking this is a system, which developers are afraid to change. Michael Feathers, in his excellent book “Working Effectively With Legacy Code”, defines legacy code as the code, which have no unit tests. This means, that system won’t bite you, if you do the wrong change. (Although customer may bite, and even sue you :-) )

Usually, such systems have additional characteristics:
there is almost no documentation for the systems
all the original development team has left
it is really hard to find, which systems this system speaks with, and what are the protocols

In my career, I was working with several legacy systems. One was a backend system for mobile carrier, which was supporting chat on mobile phones. Second was a connectivity layer for a bond trading system for a major bank. Now I am working again on a medium size legacy project, and feeling quite good and optimistic.

So, how one can deal with legacy code?
My recipe can be expressed as follows
Get It to build
Talk and Listen
Make it safe to do changes
Deliver frequently
Maintain morale
Choose you battles

Get It to build
First, get to build it automatically. Install continuous integration system, and use it. If you are not able to build the system, you are not able to deliver it, and you can not do anything else.

Talk and listen
Second, talk with customers. If possible, get to business users. Get to understand, what is valuable to customers.
Prioritize the work, and do only work bringing value to customer. Get to look, how people are using the system. This may bring you a lot of understanding of the work of system.
Use bug tracking system, so, you can keep the track of the conversation about issues in one place
Talk regularly inside team, sharing news, findings, problems and solution to them

Skim through available documentation, if any.

When starting to work with some subsystem, spend half a day-day, reading the code of the subsystem. Create an overview diagram explaining, how this subsystem is working. Such a diagram will repay very quickly, when trying to understand, where the changes should be done/or explaining, how the system works, for a new joiner on the team.

Make it safe to do changes
Legacy system is the one that people are afraid to change. So, use any tool possible to make it safer to do changes.
Cover changing part with unit tests or integration tests. Doing one tests per subsystem can bring a lot of test coverage in a relatively short side.
Write unit tests for the code that is being changed. This strategy will allow you to cover gradually most important parts of functionality with regression tests.
Consider using mocks when writing unit tests. Especially useful are extensions to mock testing frameworks that allow mocking of concrete classes. This makes unit testing of legacy code much easier.
Use code reviews of the changes done to the legacy code.

Deliver frequently
In order to maintain good rapport with customer, deliver frequently, not less then once per month (even better – once per 1-2 weeks).

Maintain Morale
Working with legacy systems is hard. That’s why really important to maintain morale inside team. Let people know before starting the work that work will be performed on legacy system. This will allow you to work only with people, who choose to work on a system. Gather regularly to talk and celebrate small victories. Let people solve problems and have fun together. If possible, never maintain person alone working on a big task in legacy system. Continuously improve state of the code, and pay attention to the business value. Notify people, when their changes are going into production.

Choose you battles
Ability to change situation on the legacy project depends very much on the size of the system. It is possible to change a situation dramatically on the 40 KLOC system project during one year. However, what can be done on 500KLOC project is quite limited. Your work on improvement may have impact only in 3-4 years, which is more, than more people working on project will see.
So, choose the battles, which you are going to fight. Maintain you forces. And concentrate on small steps, which may be performed by you, and let you project to be a series of small victories.

And one, the last but not least – have fun, while working, and live a full life.

Bookmark and Share


Alex Yakima said...

Yeah, it's funny, there's many definitions to legacy system. One is in this post. I remember Dean Leffingwell used to say every piece of code becomes "legacy" few hours after it's written. There's also understanding of legacy systems as something built on ancient technologies (COBOL, SmallTalk etc). Anyway, I think it's obvious that every definition gravitates around difficulties people have with it.

Label Cloud