Legacy is Anything Without Feedback

This post is the result of a conversation I had the other day, over a few after-work beers with Andrew Knevitt. He deserves a large part of the credit (and/or blame) for this for starting the ball rolling. Andrew was bemoaning the amount of legacy he had to deal with and I immediately started talking about code and automated testing. This wasn't what Andrew was referring to though. He was working mostly with business process and was referring to the problem of legacy business process. We all know the problems of legacy code - hard to maintain, fragile, lots of manual testing required. Legacy business processes have similar problems - clumsy, fragile, constantly out of date, lots of manual work required, and so on.

We both agreed that legacy process was a problem but neither of us could come up with a good explanation of what made a business process legacy. It's more than age - some old processes work really well but some brand new ones are out of date as soon as the ink is dry. So what makes a business process legacy? During the course of the discussion, I trotted out one of the more common definitions of legacy code - legacy code is any code written without automated tests. That was when the lightbulb went on for both of us. Legacy business process is any business process without a built-in feedback loop. But not just any feedback loop. A 2 yearly process review cycle isn't enough. It has to be fast feedback.

Automated testing is a feedback mechanism. It stops code from going out of date by giving feedback to the developers after each change. It's the speed and specificity of the feedback that gives the greatest benefit. Regular, once-at-the-end manual testing gives feedback, but that feedback occurs long after the change that is made. It also gives feedback for many changes all at once, which make it hard to pick out the impact of any individual change. Automated testing gives feedback that is specific to the change made and gives that feedback soon after the change is made, so the knowledge of what was done is still fresh.

The fast and specific feedback of automated testing is what distinguishes non-legacy code from legacy code. Legacy code - without tests - becomes old and brittle because it is hard to change without the risk of breaking something. Non-legacy code (also known as good code) - with tests - is easy to change and maintain as the impact of every change is known within minutes of the change being made.

It is, of course, entirely possible to write brand new legacy code - code that is unmaintainable legacy code as soon as the developer has hit save. It's quite easy to do (most large organisations are experts at it). All you need to do is just write code with no tests.

It's exactly the same with business processes. Most business processes do not have feedback built in. Most rely, at best, on a periodic review and many have no change mechanism at all - they are just expected to last forever, or until people complain so much that they have to be re-written from scratch. These are legacy processes. If, on the other hand, a business process has a built-in feedback loop that allows the process to change and adapt rapidly, then it will never go out of date.

It is interesting to note that while traditional project management methodologies don't have feedback mechanisms built into them, agile methodologies all do. They all have some concept like the sprint retrospective or a continual improvement mechanism like Kanban at their core. Agile methodologies will adapt themselves to new circumstances and traditional methodologies (as we have seen over recent years) can not.

It's not just having feedback that is important. Automated testing works because it's fast, specific feedback. It's the same with business processes. There is no point having a 6 monthly review. Yes, it's feedback, but it's slow and non-specific. Automated testing works because it is giving feedback on every change. It has to be the same for the business process. You need feedback on every piece of work that moves through the process, or, in the case of processes that handle a lot of work, feedback on the smallest practical batch of work. This is what Scrum does with its sprint review. It's not giving feedback on every story, but on a sprint's worth of stories - still fast and specific enough to keep the process current.

This doesn't just apply to business processes. In fact, you can generalise this to "legacy is anything that doesn't have a built-in mechanism for improving itself". Whether it's code, business processes or just ideas, if there is no feedback loop, whatever it is will stagnate. Even intangibles like ideas and relationships. An idea may have been a great idea once, but as conditions change, unless you update the idea it will cease to be a good idea. Even real intangibles like relationships are the same. Unless there is frequent and open communication within a relationship - a fast feedback loop - it can go stale.

Legacy has nothing to do with age, but it does have everything to do with feedback.