“it’s important to raise awareness among technology leaders about how technical debt and legacy systems slow down valuable development work”Gene Kim – https://www.infoq.com/articles/unicorn-project/
We are told by the experts that technical debt and legacy code is bad. But why? Because:
- Legacy is expensive and difficult to manage.
- Technical debt gives us fewer options to redesign.
- Legacy is unattractive to our developers and goes against the ideas of clean architecture, cheap cost of change and effective flow.
But there is no such thing as a debt-free codebase. There is no system built which doesn’t immediately accrue legacy.
Why? Because a successful system will have customers. If your system has customers, it will have legacy by definition. It’s how you handle your legacy, and your customers, that will set you apart in the market.
Living with Legacy
When confronted with a legacy codebase and legacy systems, you might feel a bit overwhelmed.
Learning an existing codebase can be challenging. Technical debt can mean that just building a legacy system could be difficult.
How do you make progress? Where do you make changes?
Often teams or organisations will decide that there is too much work involved in maintaining or extending a legacy system and will instead choose to build something new. The result? You now have two systems to maintain.
Newer is Rarely Better
Starting with a clean, new codebase is very appealing. A blank slate is easy. The problem is that it won’t stay that way for long. When code is deployed, things change. “Production” has its own rules. Rules means changes. Changes mean coupling and complexity. Coupling and complexity means changes are more difficult to make.
So when we look at a software system, let’s learn to look beyond the code. Look beyond the interfaces into the systems and places where it actually runs.
The Importance of Configuration Management
Many problems you might associate with legacy code are usually about legacy systems.
While you should always strive to optimise and improve your codebase, what about your systems? How much love do they get? And how much attention do you pay to them when building a new piece of software?
Systems aggregate around our software. These systems include our build and deployment pipelines, those that make it simpler to secure, and easier to monitor and report against. These systems also create more coupling, more dependency and brittleness which makes our software harder to maintain.
So what’s a simple test for seeing if your configuration management is under control? Try this:
How easily can you exactly reproduce a production problem in a non-production environment?
A Systems Thinking Approach
I believe a new approach to legacy coding and legacy systems is needed.
I believe that we have learned from Mel Conway that the system is inextricably linked to the systems around it, including the organisation itself. From that standpoint, we must view the software system in totality and not just as separate unconnected codebases.
If you can see the business, the software and the customer as a single entity, we can start to understand how every technical decision helps or hinders our codebase, our customers and our business.
As developers, DevOps engineers, SREs, system administrators, operators and engineering leaders, we can inhabit a space where we work pragmatically through our configuration changes. We see technical debt and legacy as inevitable and welcome parts of our product. We acknowledge that technical debt and legacy can arise as quickly as we remove it but we see this as a sign of success.
By learning to think about all the tools we have at our disposal and putting code in context, we learn that legacy systems and codebases are often the smallest part of the problem. Fixing our assumptions and behaviours is fundamentally more important than rebuilding software. Using good development practices in liaison with context and understanding means we can solve business problems without resorting to technical solutions.