A lot of people I talk to are working with legacy code – old clunky systems that are hard to work with. These systems are slow to change, poorly understood and often fragile.
The often seem to rely on one or two gurus, who know the tips and traps for working with them.
What is less obvious to some teams though, is that they are also working with legacy processes and tools, old clunky ways of getting things done that are hard to work with. These ways of doing things are slow to change, poorly understood and often fragile.
I include expense processing, code reviews, issue tracking tools and even collaboration tools and internal web pages.
But these systems are not the law, they are not some ancient truth handed down in a great tome, where challenging them is the equivalent of rejecting the gods and forgetting the wisdom of the ancients, they are just old constraints we have not had the time or the passion to deal with.
But if we did not have the time to deal with them last year, and we don’t have the time to deal with them this year, what will happen next year?
Each month these legacy applications, clunky processes and even expectations of how we work together become slightly more obscure, slightly less understood and slightly more fragile.
Now we want to change them, they are overwhelming and we talk about having to form a task force, a project or a big budget to tackle them in one big hit.
The problem is that we can never win that way. The old systems are aging every day, relentlessly becoming more baked into to how we work and more likely to become a constraint. It is entropy in action and the forces of entropy do not take a break or wear out.
So day in, day out, chaos and ignorance grow, short-cuts are applied and workarounds get us through our day.
From time to time someone attempts to tackle something but everyone else just smirks and goes back to their complaining. It is all too hard.
But nothing about the above tale of doom and gloom has anything to do with technology.
Small wins, constantly applied create excellence
It is tempting to think we have to replace a whole legacy approach or system at once. It is tempting to believe that we need everyone to agree to our plan before we execute it, but it is also tempting to believe that we need big upfront design and a fully developed product before we can move forward.
Big up-front plans which consume a whole team’s time for weeks, are not efficient. We no longer think we should sit around pontificating before doing something new. So why do we not apply the same thing to looking after something old?
Small concessions, over time, mean that we accept we will lose. But on the other hand small, micro-wins, consistently applied over time mean that we are always moving toward excellence.
So maybe the term “legacy system” should be replaced with “the world we accept today.” Maybe we should actually celebrate that a mainframe was built so well it is still there a generation later and maybe we should celebrate that the work someone did 5 years ago on our appraisal system worked for them in their circumstances.
But we should also take over the mantle and instead of accepting what is not working, we should constantly make small tweaks. The problems will not all be solved in the near future, but they will get better over time.
And I believe a better way to think is “can tomorrow be better than today?” rather than “can we fix everything at once?”.
Accepting that we can make constant small changes means that we just take a little longer to get things done today, we we take a little less time tomorrow. It accepts that we need to spend a little more time making changes, spreading skills and iteratively making things easier.
Most importantly though, it requires a change in mindset – from focusing on building new things and then forgetting them, to maintaining and improving old things. We need to realise that maintenance, quality improvement and refactoring how we do things are constant, valuable activities.
We need to prioritise getting better over adding new things to the pile of things we have already.
James King 