This is part of a new mini-series looking at Legacy software - the term "legacy" is often seen as 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 introduce three methods to address legacy software: I briefly compare the three options and will dig further into each in future episodes.
Or listen at:
Published: Wed, 10 Aug 2022 15:50:27 GMT
Transcript
Hello and welcome back to the Better ROI from Software Development Podcast.
This episode is part of 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 introduced it and I've talked about how all software is on a sliding scale rather than an absolute of legacy or not.
I've talked about the impact based on just how much effort the software development industry puts into trying to explain it, using terms like technical debt, the broken window theory, the messy campground, etc. They are all shared warnings that seemingly small problems mount up over time until the system is no longer viable - leading to expensive replacement work for something you've already invested in.
And I've taken a look at some of the causes of how we get legacy software.
In this episode, I'm going to start looking at some options for addressing legacy software once you've found it. I will briefly compare three approaches to dealing with legacy software, with a further episode on each to go into more details over the next few weeks.
The three approaches I will look at are:
- Evolution - continuous improvement to the existing system to bring it out of its legacy state
- Revolution - the wholesale replacement of the system with something new
- And Outsourcing - using a third party to either maintain or replace the legacy system.
Of the three, I will generally favour evolution and I'll go through my reasoning during this episode.
Evolution.
My reasoning for evolution is simple - you already have a working system that has considerable investment in it, why replace it?
If your car has a punctured tyre, then you'd replace the tyre. You wouldn't buy a whole new car.
But often the call for a new system, the Revolution, becomes too great and we skip any attempt to fix what is broken. You can probably argue this is partly a symptom of our throwaway society, but I think part of this is the preference of wanting to work on the new, the green field - and the kudos that is associated with doing so.
Who would you hire; the person that led a modernisation project to replace a mission critical legacy software, or the person that just got on quietly and incrementally fixed it over time?
One is big and showy and one is a little bit dull.
Our predisposition is to be impressed with a big, shiny achievement. We, and the rest of the hiring market, gives so much more weight for the seemingly bigger complex task that saved the organisation. We don't seem to attach the same level of acknowledgement to the same saving of the organisation, but done in a much more cost effective manner.
And developers prefer the building new - again, part of this is reinforced by the market and the kudos of building new and shiny, part of it is simply not having to concern ourselves with having to understand the old, which can be very difficult in really legacy systems.
So with so many calling for Revolution, why consider Evolution?
In many cases, I think it would be more practical, more cost effective and a better outcome for the organisation. You've already invested in your existing system. It may have been developed over years or even decades.
While Revolution will hopefully utilise some of that prior learning, there will be generally investment needed to pull that learning out of the existing system. Thus you are potentially paying three times:.
- Once for the original legacy system
- Then again for extracting that knowledge from the legacy system
- And then again to reproduce in the replacement system.
That isn't to say Evolution doesn't bring its own challenges. Bringing the legacy system up to an appropriate level in itself is not without additional cost and complexity - and doing so can often feel like you're trying to replace the tire of a moving car.
But in my opinion, the Evolution is the cheaper and less risky approach for the organisation, all because it can be done in small increments.
But we shouldn't assume that Evolution will not allow us to transition our system over time. There is no rule to say that the system in question should remain on the same technical stack or in the same structure over time, just that it is done incrementally - reducing the risk that comes with the big bang Revolution approach.
In the classic scene from the UK sitcom series "Only Fools and Horses", Trigger claims that he's had his road sweeper's broom for 20 years. But then he adds that the broom has had 17 new heads and 14 new handles.
"How can that be the same broom then?" Asks one of the other characters.
Trigger produces a picture of him and his broom and asks "What more proof do you need?"
The broom Trigger has is fundamentally a different broom than he started with, but it still does the same job he needs it to do since day one.
While I favour Evolution, there can still be a case made for Revolution, the entire replacement of the legacy system.
I would, however, repeat my concerns that too many organisations jump into Revolution before fully exhausting, or even attempting, Evolution - and often do so without fully exploring what Revolution means.
For example, it is often felt that because we already have a blueprint in the legacy system, it should be easy to just replace it, but without any of the legacy problems.
This is often the first mistake. We are assuming that Revolution will solve the legacy problems. I've seen it happen that the replication is so true to the original that many of the legacy problems are carried over. We have it in the old system, so we must need it in the new one.
We also find new problems.
By the nature of having a legacy system for a period of time, we generally find that we are at least aware of all the oddities of the system - all the strange behaviours and quirks of the operation and maintenance. For a new system, we have to discover these anew.
We can also find that replacement being built is a constantly moving target. A replacement of any substantial system can take months or years, during which time the business needs to continue to operate - continues to need to adapt to market pressures. As such, the needs of the new system changes, possibly in line with those same changes being made to the legacy system.
I've seen Revolution projects start with the intention of running for two years, only to reach the end of that period, then have to extend the work by another two years due to how much the business, and the legacy system, had moved on in that period. And the last time I checked, that specific project had been extended a further year with completion still feeling like a distant goal.
And of course this has all the similarities I've discussed previously with any large project - they are simply too expensive and risky a way to deliver software.
There is, however, a caveat that I would add; this is dependent on the size of your software product.
For any reasonable size and complexity. I would definitely recommend Evolution over Revolution - the small incremental changes over the massive big bang.
However, for a small product, for example, a single microservice (as I introduced in episode 17), then Revolution, a complete replacement, would be much more practical given the size of the product. By its very nature, you are limiting the risk to the organisation. By its very nature, a full replacement of a microservice can generally be achieved in a few weeks.
Conversely, of course, a microservice, again, by its very nature, is unlikely to fall into the legacy software category as easily as is so much smaller and self-contained. It is in a much better starting point than the large monolith system.
That isn't to say that the underlying technology can't become obsolete over time, at which point the Revolution approach to replace wholesale would indeed be a practical approach.
And finally, I wanted to introduce Outsourcing as an option. I've been clear in previous episodes that I don't particularly favour outsourcing for software development. I found that it's a fallacy to assume that outsourcing will produce better results than internal teams. And in most cases, I would steer clients away from it.
However, for legacy software, I think there's two possible reasons for considering Outsourcing:
- You're unable to recruit or retain technically knowledgeable staff
- Or you're effectively buying a replacement product.
If you find yourself with a system built in technology that is so dated it is next to impossible to recruit or retain technical staff directly, then specialist Outsourcers may be required. I believe many banks have taken this approach with their COBOL systems - having to rely on specialist outsourcers to have the necessary technical skills to keep it running and operational.
And while this might help in the short to medium term, I wouldn't consider this a permanent solution. Having such a critical asset to your organisation outside of your direct control is bad enough, but the system is still legacy and the situation is not going to get better on its own. Realistically, this would need to be paired with some form of plan for Revolution replacement of the system.
The other option is effectively replacing the legacy system with a product that the Outsourcer already has. And if the needs of your legacy system are close enough match, this could be a good idea.
I would, however, caution against this if the legacy system is providing your organisation a differentiator in the market. As I've commented before, I favour build over by.
In this episode, I've summarised three approaches to addressing legacy software:
- Evolution - continuous improvement to the existing system to bring it out of its legacy state
- Revolution - the wholesale replacement of the system with something new
- and Outsourcing - using a third party to maintain or replace the legacy system.
I firmly believe that Evolution should be the assumed starting point for any attempt to address legacy software.
This is at odds with many within the software industry who would just opt straight for Revolution. But in many cases I would question their motives. Are they too caught up in the potential kudos or the perceived ease and fun of working on greenfield projects? In short, are they focussed on the benefits to themselves over the organisation?
For the organisation, Evolution generally provides a better outcome as it reduces risk and attempts to utilise existing investment.
Over the next three episodes, I would take a deeper look at each of those three options in turn.
Thank you for taking the time to listen to this podcast. I look forward to speaking to you again next week.