This is part of a new mini-series looking at Legacy software - the term "legacy" is often seen a positive - yet within computing it is a negative term generally uses to indicate the need to replace hardware or software. In this episode, I'll talk about the impact of Legacy software and why the software industry invests so much effort into addressing.
Or listen at:
Published: Wed, 20 Jul 2022 15:34:31 GMT
Links
Transcript
Hello and welcome back to The Better ROI from Software Development Podcast.
This is the second in a series on legacy software - What is it? How does it occur? And the various strategies to deal with it.
In the last episode, I gave you an introduction to legacy software and I talked about all software being on a sliding scale - rather than an absolute being legacy or not legacy.
In this episode, I want to look at the impact of legacy software.
In short, the impact of software becoming legacy is one of the greatest challenges we have within software development. This may seem like a controversial statement even to a software development professional, but I say this because of how much effort the software development community has put into finding different ways to express how poor a state a software product has gotten into.
There are many related approaches to allow us to have a conversation over the current suitability of a given software product.
Take, for example, Technical Debt, which I discussed in episode 16 - a metaphor of using financial debt to explain the rightness of our software. Every time that we cut a corner or fail to resolve a problem with the code, we incur technical debt.
And like financial debt, this can be used to gain forward momentum - it can be a good thing. But like financial debt, it has to be managed effectively. Otherwise, the debt becomes too much to service - ultimately, leading to a software system no longer being viable due to the overwhelming debt - which almost certainly will be accompanied by the system then being described as legacy and plans being drawn up to replace it.
Robert C. Martin, or Uncle Bob as I introduced him in episodes 51 to 60, described it in a possibly simpler sense in his books. He just described it as "messy code". Code that has simply become a mess, making it difficult to understand or change. Uncle Bob also paraphrases the Boy Scout principle "always leave the campground cleaner than you found it" by asking that every developer "always leaves the code cleaner than they found it".
Michael Feathers, the author of the Working Effectively with Legacy Code book, describes the idea of "code that developers are afraid to change".
The authors of the Pragmatic Programmer series of books provide us the cautionary tale of broken windows. They talk about a building with one broken window will likely attract more. If the building is not kept in a repaired state, then no one feels the need to care about it.
These theories share commonality.
They all talk about seemingly small and insignificant annoyances occurring over time.
And they all warn us of the danger of that going unnoticed until it's too late.
And this strikes at the heart of the problem for us as business leaders. The danger we have is by the time we're aware of a problem, it's too late.
The Technical Debt that we've accrued is so high that we cannot service it any longer.
Our building has so many windows put out that realistically it's a wreck.
The campsite is so littered and cluttered that it's not safe to occupy.
Our software is in such a state that our software developers are scared to make any further changes.
Because unlike the software developers, we're not living in that software codebase day-to-day. We're not able to see just how poor a state it's getting in. We're relying on other people to tell us - and we may hear the occasional moan of "Oh, that's a bit difficult to work with", or things getting slightly slower over time to make change - but it probably doesn't occur to us that these are the warning signs, these are the signals that we've got impending problems further down the line.
And ultimately, this is the critical lesson for us as business leaders. We're not going to know how bad the code base is without relying on our software development team. Our software developers should be coming to us and telling us "we've established this amount of debt", "we have these areas that we have concerns about", "we really do struggle trying to do changes to this system".
These are the conversations that we need to be listening to with our teams. Our teams are working with that codebase day in and day out. They are going to be best placed to tell us if there is a problem - and if it is growing.
And of course, it's so much easier to address if we know about it early.
Going back to that Technical Debt argument, if we're taking up small amounts of financial debt, it's great if we know about it - it's great if we can make plans to pay that off quickly and in a controlled way.
If, however, we are acquiring financial debt without any control or any plan to pay it back, then yes, we are going to reach a point where that debt becomes unserviceable. Now that's easier to see with financial debt. You can see the bank account, you can see via the financial teams and the reporting where you are with that debt. That's not going to sneak up and surprise us.
Technical Debt, and the various other analogies that I've used during this episode, are much more subtle - much more difficult to spot for a business leader because we're not aware of them.
And if there's one overriding message in this episode - and indeed the whole of the legacy series - is you need to be aware that these things can happen. Not only can, but will if not managed correctly.
For all the best intentions, your wonderful system that you've invested a lot of time, money and effort to build will at some point become legacy, will become too heavy of a Technical Debt to actually service. You have to actively work on it to make sure it's viable and continues to be viable all the time that you need it as an operational system.
In this episode, I've tried to emphasise just how important it is that we keep track of how far down that legacy scale that our software is going.
How much Technical Debt have we incurred?
How many broken windows do we have?
How many messy areas do we have that need to be resolved?
How scared are our developers to make those changes?
Because if we're not keeping an eye on this micro level, eventually it's going to be a point where we can no longer work on that software. At which point we will be drawing up plans for its replacements. And that in itself is a big, expensive task - a big, expensive task that ideally we want to avoid as both software developers and as an organisation - we're spending large sums of money to potentially recreate something we already have.
And this is why I believe that the software development industry spends so much time trying to find ways to explain it - trying to explain the dangers by using these different analogies:
- Technical Debt.
- The broken window analogy.
- How clean is the campsite.
And various other ways of trying to get across the state and correctness of our systems before it becomes too late, and we have no choice other than to abandon the existing system to which you would have invested heavily - and then have to invest again on a replacement system.
In next week's episode, I want to look at some of the causes that can lead to these problems. The problems that lead to incurring that debt, those broken windows, that messy, messy campsite.
Thank you for spending the time listening to this podcast. I look forward to speaking to you again next week.