Legacy systems

Last week I stumbled upon a nice quote from Corey Quinn that I shared via Twitter:

This tweet received quite some attention and I had a few little discussions with other people via Twitter. Those discussions were actually quite constructive. Still, I noticed that the limit of 280 characters makes it hard to share some of the details that I think are important. Therefore, I decided to write this post.

Old is bad

I guess you also attended some presentations or discussions where people contemptuously talk about “legacy systems” – usually in deepest disgust, almost spitting out the word “legacy” as if they were talking about something utmost hideous. Or you experienced the more devious variant where people start their reasoning with something like “We all know legacy systems are bad and thus …”, suggesting that it is a commonly accepted fact that legacy systems are a bad thing.

In those situations I often feel tempted to ask “I do not understand why legacy systems are bad. Could you please explain that claim?”. Well, up to now I was polite enough to suppress that urge. But – more importantly – why do I feel that urge?

“Legacy” usually means “successful”

Most so-called “legacy systems” are the core systems of a company. They are usually mission-critical and the main revenue streams of a company directly flow through them. Stopping any of them usually means that the whole company (or at least a significant part of it) immediately would come to a screeching halt.

Those systems also tend to capture much of the collective business knowledge that was built up over many years in a continuous demanding struggle against the market. Actually, more often than companies dare to admit those systems are the only place left where this knowledge still can be found. The business and IT people who originally gathered the knowledge and turned it into code often long left the company.

That is why I have the deepest respect for legacy systems. They are the lifelines of companies. They capture business knowledge and wisdom that often cannot be found in any other place. Or, as Corey Quinn wrote, they are the systems that actually make money.

“Successful” means “changed often”

Okay, quite often you have to dig quite deep into those systems to excavate the knowledge and wisdom hidden in them. Why is it often so hard to understand and change those systems? Why do they often feel like a showcase for technical debt? ¹

I think, the primary source of this effect is the fact that successful systems need to be changed often. As Meir Lehman pointed out already 1980 in his great paper “Programs, life cycles, and laws of software evolution” ², most programs need to be adapted continuously to respond to the ever-changing needs of their environment.

Freezing a program and not touching it anymore already means decay, i.e., most programs must be continuously changed just to keep their value. We have not even mentioned changes that are needed to increase their value.

Additionally, the ever-changing needs of the environment often do not wait until they match the schedule of an IT organization. Especially if the need for change is driven by the market, the decision is either “respond now” or “lose value” (i.e, money or even market share).

This means, any successful program needs to be changed continuously – and often the schedule for the changes is driven by outside forces that the affected organizations cannot influence.

“Changed often” means “increasing complexity”

This goes well with the second law of program evolution that Lehman described in his paper:

The law of increasing complexity

As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.

In other words: programs never become simpler when changing them, unless you explicitly invest time and energy to reduce program complexity.

If you combine that finding with the regularly tight schedule for often hard to anticipate changes that are needed in the most successful and thus most critical programs of a company, you probably get an idea why those programs look the way they look several years after their initial release.

It is not that the people who worked on those systems were lazy, careless or even malicious. Usually they did the best they could (and sometimes even a bit more). But there is a price you pay for working on a highly successful, mission critical system of a company: there are always tons of changes that need to be made and there is always the pressure to make them as soon as possible.

Turning the idea around: If you never have a problem to keep the code you are working on nice, clean and tidy, if nobody ever presses you to get more features and changes done in less time, you most likely work on a system that is irrelevant for your company.

Summing up

Legacy software usually is successful software, often mission-critical, the backbone of the company. Especially successful software needs to be changed all the time to keep its value and changes tend to make software more complex. Thus, it is not a surprise that the most successful software of a company often looks like a playbook for technical debt.

In my engagements, clients often apologize for the bad condition of their software. I usually answer that for me this is a good sign because then we most likely talk about a relevant and highly successful system. Sometimes, I add with a wink that I would be worried more if the software would look like a case study for perfect software development, because then we probably would waste our time with some irrelevant system no one cares about.

That is the reason why I stopped saying “legacy systems” and replaced it with “core systems”: to express that we are talking about systems that were vastly successful for many years and thus we should treat them and their developers with the due respect.

This does not mean that I do not curse silently sometimes while trying to elicit some buried knowledge from the guts of those systems … ;)

But, couldn’t it be different?

PS: You might wonder why I did not touch the “… unless work is done to maintain or reduce it” part of Lehman’s second law of program evolution. Actually, I will discuss that in the next post. I just wanted to keep this post short because over the Easter holidays you probably have better things to do than reading long blog posts … ;)