“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/
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 that a new approach is needed to legacy coding and legacy systems.
I believe that we have learned from Mel Conway that the system is inextricably linked to the systems around it and that includes the organisation itself. From that standpoint, we must view the whole of a software system in totality – and not just as a separate codebase to improve.
If you start to see the business, the software, and even the smallest decisions we make as a single entity, we can see can start to understand how every decision either helps or hinders our codebase, our customers and our business.
Can we, as coders and software engineers, as DevOps and SREs, as system administrators and operators, inhabit a space where we think like this about every change? I believe we can.
How?
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 practice in liaison with context and understanding means that we can solve all business problems without resorting to complete rebuild.
Context is everything. I will explore this through a series of workshops and seminars on this subject.
Who am I?
My name is Richard Bown. You can find out more about me on my blog or drop me a line using the contact page.
Want to stay informed? Then sign up for the workshop’s waitlist.