Legacy systems are getting a bad rep in the industry. In this post, I want to investigate why that is, highlight some of the aspects that make legacy systems interesting, and explore some ideas on how we might get around some of the frustrations that legacy systems cause.
Where does the bad reputation of legacy systems come from? From the surface it would seem that the fact that you have legacy systems is a good sign: It means you offered something that was and still is commercially successful. Otherwise, you could just drop all activities and focus on something else. The fact that you still need to support a system means that it is still addressing a real, proven need. So why are people not full of joy when it comes to legacy? Let us consider different perspectives:
The Business
From the perspective of the company leadership, the existence of a legacy product or system which is still generating money is a priori, not such a bad thing.
However, their challenge is to keep the flywheel spinning: The money generated by this system will dry up eventually and by then you will want to have a new cash cow in place. The challenge thus becomes investing the minimal amount that allows securing the revenue stream and allocating as many hands as possible on the next generation.
Thereby, the maintenance of the legacy system becomes a risk management exercise: What is the minimal team that can be allocated on maintenance tasks to avoid a catastrophic scenario resulting in a loss of cash inflow.
In short, you don’t want to invest in legacy systems as every penny spent here cannot be spent building the future.
Management
Consequently, the company’s hopes and dreams are attached to the new initiatives. This is where new investments will be allocated and, for managers, that is where big victories can be scored.
Conversely, the best you can do managing a legacy project is securing the existing cash flows. There is not much glory to be gained here. The only scenario in which you will be noticed is if you screw it up. The downside risk is large, the upside, if you do well, is limited.
Furthermore, a manager’s status in the organization is often measured by the number of people below their name in the org chart. The fastest way to expand this is by hiring more people into your teams – a promotion into an existing vacancy is a much rarer event.
If you are responsible for a legacy project, chances are that your team size will shrink rather than grow as talent is shifted towards new initiatives. Paradoxically your team size is most likely to shrink if you are successfully able to stabilize the project and you are most likely to increase your influence if the system continues to cause problems.
Engineers
For us engineers, legacy projects can constitute a career risk: Today’s career trajectories usually include stops at several different employers. The best insurance as an engineer against economic downturns, political intrigue, or simply a stagnating salary is to remain attractive to the job market.
By their very nature, legacy projects involve technologies past their prime time. At best, the technological bets that were made during the inception of the project were sound and you are working with stable, mature but slightly out of fashion technology stacks. At worst you find yourself learning a niche technology that has been discontinued or superseded with almost no relevance to a potential future employer.
Next to this career risk, there is also a messaging problem: As it is clear that the business wants to allocate as much of their top talent as possible on new initiatives, how should I understand the fact that I was not sent there? Am I not good enough? We are a profession already plagued by imposter syndrome, this implicit messaging does not help.
Sometimes there is furthermore a second group of engineers in this context: The ones that have built their entire career and professional identity on the project which is now past its prime. For these folks, it is sometimes hard to accept the decline in the importance of “their baby”.
What I like about legacy systems
While all of the above points are real, I still have a bit of a weak spot for legacy systems.
First of all, there is a certain archeological aspect to legacy code. Usually, by digging through the code of several decades, you can trace back parts of the history of a company. What the priorities and ambitions were at the time is often reflected in the abstractions that were chosen. Technologies were selected to solve what seemed to be the most burning issues at the time and it is interesting to observe these decisions from the comfortable vantage point of the future with the luxury of hindsight.
A second aspect that should not be neglected is that legacy systems have proven their value. They constitute a problem-solution match. Any line of code written for a new greenfield project has a significant probability of never actually providing any tangible value to a customer. A change made to a legacy system, however, has a very high chance of actually delivering value. After all, people rely on this system right now!
The fact that legacy projects don’t automatically attract people with high ambition has its positive side. Ambition can be a good thing, but it can also hurt a project if the ambitions of the individual are not aligned with the interests of the team and the organization.
Finally, bringing legacy systems in a shape that reduces the opportunity cost associated with their continued development and maintenance is in itself an interesting challenge, both from a technical and a social perspective.
A way out?
Given that working on legacy systems does have its perks, how can we make it less painful and maybe remove a bit of its bad reputation?
As a business, I think you should make sure that the incentives of the individuals working on such a project are aligned with your incentives as an organization. That means managers and engineers need to be comfortable on a job whose goal is to make themselves redundant. There are two aspects to this: The people involved need to accept this mission as a worthwhile challenge. Furthermore, however, they need to be reassured that succeeding in this challenge is not against their own best interests.
What this looks like in practice will differ from team to team and person to person. Here are some ideas, however:
- Make sure your engineers on these teams have access to „innovation time“ which they can use to stay up to date.
- Maybe managers can keep their reports even after a transfer to a different team, thereby building a network in the new structure of the organization.
- Reward the act of making yourself redundant. Is there a team you keep pulling people out of and you still don’t hear any alarms going off? They are probably doing a good job.
- There might be people in the organization that like me find the graceful phasing out of old code an interesting challenge. If you are open and honest about the contents of the mission, these people might come out. I could see some interesting team dynamics around milking old projects as much as possible before putting them to sleep.
By identifying and mitigating the downsides and getting the best out of the upsides, I am convinced that legacy code maintenance can be turned into a far less painful experience.
The Solution Space 