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 some of the causes behind how our software can become "legacy".
Or listen at:
Published: Wed, 27 Jul 2022 15:59:10 GMT
Links
Transcript
Hello and welcome back to the Better ROI from Software Development Podcast.
I'm currently running through a mini-series looking at Legacy software - what it is, how it occurs, and the various strategies to deal with it.
Over the last few episodes:
- I've given you an introduction to it - and I've talked about all software being on a sliding scale rather than an absolute of legacy or not
- And I've talked about the impact based on how much effort that the software development industry puts in to explain it using terms like technical debt, the broken windows theory, the messy campground - all of these attempts to explain it, they all share warnings that seemingly small problems mount up over time, until the system is no longer viable
- Which ultimately leads to expensive replacement work for something you've already invested in.
In this episode, I want to look at the causes.
The number one cause is a simple lack of awareness.
I talked about this in the last episode; that this only really becomes a leadership issue when it's too late. It's why the software industry is putting so much effort into trying to explain it. Our technical debt becomes so high that we're no longer able to service it. Our building is so derelict that it's falling down. Our campsite is so messy that it's not usable. Our teams are scared to make changes or we simply cannot recruit.
And while it's built up over a series of small little things over time, it builds up to a point where we're having to seriously consider an expensive replacement of a previously working system.
For most of it, it's simply an unknown unknown. It's simply not on the leadership radar until it's too late. Simply knowing it can get to that state, sorry, will get to that state, helps us go a long way to address the causes.
So for me, for leadership, to have that awareness that this can, and will happen, is the number one thing that we need to address.
Let's move on to some of the reasons how it can happen.
Long term listeners won't be surprised to hear me saying that I believe that "project" thinking is one of those causes. Project thinking produces us to have no thought or focus on the ongoing life of the software. It encourages a short term focus - something that I've been talking about so much during my podcast episodes, about moving that focus away from project to product thinking - thinking more about the whole lifetime of the software product.
Projects are by nature to deliver a specific outcome by a specific date. Thus everyone is tunnel focussed on that. Thus issues will be raised, but ignored by well-meaning middle management in favour of the soup-du-jour, the latest shiny thing, the latest priority number one.
And that's the entire focus on that one priority. We overfocus on the short term at the expense of the longer term. Which is why I love the technical debt analogy so much.
It's easy to equate as a focus on the short term benefit - maybe that holiday you've always wanted or a sports car - but you're then likely to struggle to pay off the debt over the longer term.
The next cause I wanted to look at was simply a lack of organisational interest.
Maybe because the software has just always worked, many organisations develop an apathy of "it's always been that way". And that's an easy state to get into with an old system that just works and is rarely ever changed.
An example of this can be seen in the banking sector; the use of the COBOL programming language. Now. I was taught COBOL in college over 30 years ago, and even at that point it was considered a dead language.
However, from an article written in 2018:
"Companies involved in keeping COBOL-based systems working say that 95 percent of ATM transactions pass through COBOL programs, 80 percent of in-person transactions rely on them, and over 40 percent of banks still use COBOL as the foundation of their systems."
I'll provide a link to that article in the show notes.
The problem is that the COBOL based systems just work and indeed they continue to do so.
However, they represent two problems:
- They're difficult to staff
- And difficult to innovate.
There are many stories of ageing staff being brought out of retirement because that technology was no longer being trained. And innovation is difficult, making it difficult to compete with "Fintech" innovators.
And as such, many of our traditional banking organisations have been taking the hit for both the higher staffing cost - keeping people out of retirement - and running the risk of losing significant market share due to the inability to innovate.
The next cause I want to look at is a lack of software development professionalism.
We are a young industry and one that hasn't really established professional characteristics. Something I talked about when I discussed the programmers oath back in episode 51 to episode 60. As such, we developers may feel things are incorrect and need addressing, but we feel as if we need to seek approval, often feeling like we need to justify our concerns and force it onto the table.
And to be honest, that isn't what most developers got into the industry for. We joined the industry to solve problems, not to justify the work that seems obvious to us.
Would you expect a doctor to do an operation without painkillers and antiseptics? Would you expect a pilot to take off without doing their pre-flight checks? These are characteristics of professionalism, and even if you are paying for the operation or the flight, you would not expect to be telling the professional to "ignore that and get on with what I'm paying you for". You would expect the professional to do what needs to be done, even if you haven't explicitly asked for it.
But with software development we effectively incentivise wrong behaviour. Our recruitment, promotion and remuneration is based on getting tasks done - the adding of new features - rather than the hygiene and rigour that is needed to avoid our software going down that legacy path.
And that feeds into the bragging rights, the kudos that we as developers value - surely we are going to value the same thing as we get paid and promoted for. And thus we, as a development culture, will put more weight behind the new and shiny rather than seeming drudgery of keeping an existing system well maintained.
And that mindset will often result in developers leading the call for the rewrite of legacy systems. It's much more fun and profitable to build new than fix the old, something that I revisit later in this series.
The final cause I want to talk about is the loss of key staff.
This is slightly different than some of the other causes which build and build over time. This can feel like it happens overnight. Take, for example, you have a hero developer.
That person you always go to to get the job done. They're the most competent, most hardworking developer you have. The industry sometimes describes this as the 10x developer, the developer that knows everything about the software and can do more than ten other developers.
And in this situation, it can be alluring to the organisation and the developer in question. I know I've been that developer. The kudos can be quite addictive.
But it's a dangerous place to be. You're generally find that that hero developer is the only one that does know the software. They were able to do more than anyone else because they're the only one that really understands it. They've probably built it from scratch. It's their masterpiece.
But what if they leave?
Without that shared knowledge, what seems like a viable, thriving system suddenly appears to have become legacy overnight. But in truth, this hasn't happened overnight. This is likely to have happened over time with less and less people understanding or working on the software until such point as there's that single dependency, that single point of failure.
From a business risk perspective, this is massive. All of that dependency is on a single individual. But it goes unnoticed - the software works, changes are being made - right up to when that hero leaves. Then the problem becomes apparent.
If they knew about it, I doubt it's a risk that many business leaders would accept ahead of time.
But this comes back to the unknown unknowns, the simple lack of awareness within leadership that this can and will be a problem.
In this episode, I've looked at some of the common causes of legacy software.
By listening to this episode, you've already improved your position - well done. Simply knowing that it can happen is a massive step forward on most business leaders. Once you know it exists as a risk, you can treat it as it is: a risk.
If you can assess the risk of your software through your development teams, you are much more likely to avoid a disaster of it becoming so legacy; so legacy that the only option is to replace at great expense.
And as with any risk management, you need to ensure honesty throughout the system. I've seen people massage risks or audit data to avoid looking bad. But this just sets false expectations and may be more dangerous than not even monitoring the risk in the first place.
Please, as a leadership team, we need to avoid shooting the messenger. Rather praise them for saving you in the longer term.
In next week's episode, I'll look at how to apply a risk management approach to your software products.
Thank you for taking the time to listen to this podcast and look forward to speaking to you again next week.