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. Two weeks ago, I introduced three methods to address legacy software:
Or listen at:
Published: Wed, 24 Aug 2022 16:53:36 GMT
Transcript
Hello and welcome back to the Better ROI from Software Development Podcast.
Over the last few episodes, I've been running a mini-series looking at Legacy Software - what it is, how it occurs, and various strategies to deal with it.
And over the last few episodes, I've introduced it - I've talked about all software being on a sliding scale rather than an absolute of legacy or not.
I've talked about the impacts based on how much effort the software development industry puts in to try to explain it, using things like the technical debt theory, the broken windows theory, the messy campground example. These 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.
I've taken a look at some of the causes of how we get legacy software.
And in episode 144, I looked at three approaches to address legacy software:
- Evolution - the continued 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.
And in last week's episode, I took a deeper dive into the Evolution option.
In this episode, I want to take a deeper dive into the Revolution option.
While I clearly favour Evolution over Revolution, I do understand there are times at which Revolution is the only practical approach. So in this episode, I want to provide a number of hints to help succeeding at Revolution.
In my opinion, full replacement projects can be one of the most difficult software development projects to get right. There are, unfortunately, many places where they can go off the rails, generally due to two factors:
- One, the size of the project
- And two, an existing system already existing.
That latter point shouldn't be overlooked. But unfortunately often is. The existence of an already working legacy system can present us with some challenges on top of creating the new one:
- It may need additional changes
- It may not be well understood
- It may be well liked by the users
- And it can come with unexpected impacts when switching over.
Let's take each of these in turn.
It may need additional changes.
You are creating a new system because it is important to your organisation - which would indicate that the legacy system is also important and likely needs continual change. While I've seen organisations attempt to implement a change freeze on the legacy system while the new system is being built, there are generally circumstances that still require change, be it regulatory, security or simply a critical business need. Rarely is it practical to implement a change freeze for any great length of time.
And by having to support this change, then you have the impact of moving goalposts and the danger of two teams - one supporting the legacy and one building the new system. And dependent on how much change is allowed, it can prove almost impossible for the new system to catch up - they will always be chasing changes being made to the legacy system.
My advice in these instances is to make the same team responsible for both the legacy and the new system. This at least gives them clear visibility of the changes in the legacy system so they can replicate it into the new system. It should also be obvious from their output if there is too much change being allowed to the legacy system.
If the system is too large for the team to support both the legacy and new, then I suggest splitting the system by functionality and assigning to different teams - rather than splitting the work between legacy and new.
So for example, if you are rewriting an e-commerce website, then have one team owning the product search, one team owning the shopping cart, one team owning the order processing, etc. - with each team owning both the legacy and the new functionality.
Let's move on to it may not be well understood.
One of the reasons we may be choosing to rewrite a product is because the legacy system is not well understood. Or maybe we've lost the key developers. This lack of understanding can be a key problem in replacement projects that expect to use the legacy system as reference material.
Generally I would caution against replicating a legacy system too closely. There is a real danger in replicating parts that you simply do not need, which of course can be incredibly wasteful. As I talked about, in Evolution, there will often be parts of the system that are simply no longer used.
There is going to be no benefit to the organisation by blindly implementing them into the replacement. I've seen organisations take this approach and get too caught up on the gap analysis of missing features, rather than asking the question of what minimal features are critical to success of the replacement.
However, it is rare that any replacement project won't attempt to use some part of the legacy system for reference.
In those situations. It can be incredibly frustrating to the leadership team that a replacement project appears to be stalling while it attempts to extract the hidden knowledge within the legacy system. Leadership teams could be forgiven for thinking that if we already have a legacy system, we should be able to use that to guide the replacement project.
However, as I've said, generally, one of the reasons we are replacing the legacy system is that it's poorly understood. Now this can seem a little catch-22, especially if by understanding the legacy system to educate the replacement, have we actually solved one of the major problems that puts on the replacement project path in the first place?
In general, I'd advise early in any replacement project to highlight the "known unknowns" - those things that we know we will need to research ahead of time. This can be used to drive the communication with the leadership team and prioritise key activities early. There is nothing worse than a replacement project stumbling to a halt, for want of the knowledge, still locked away within the legacy system.
Also, if done early, this may be a good opportunity to review if the Revolution argument still makes sense - or have we done enough to actually make the Evolution approach more appropriate?
Let's move on to it may be well liked by the users.
This is an easy one to overlook. Any system of any age will have a level of familiarity with its users, and while it may be a sensible decision to replace, there may need to be some hearts and minds works to convince the day-to-day users.
For those users, a change of system may not just be unexpected, but be an unwelcome impact to their day-to-day work. They're undoubtedly busy and focussed on their own targets and goals. Why would they want to engage in a project that is perceived as causing them more work testing, training, attending workshops, etc. all for no obvious gain?
In most cases, any work will need to be accompanied with a communication piece to explain to those users why the change is needed, how it is to be approached, and the expected impacts on them.
And this should be done early.
If you're unable to convince them that there's a genuine organisational driver for this, then I'd question if Revolution is the correct approach.
If the existing users are unable to provide the support, for example, simply not enough time in the day, again, this may be a reason to revisit any Revolution approach. Certainly I've seen resolution projects suddenly have a very different ROI calculation once you factor in the additional cost incurred by the users, such as the recruitment of additional staff to help with the transition.
With any large project, often the communication strategy is what will make or break it.
And finally, I want to spend some time on the impact of switching from legacy to the replacement.
It is a given that no large project will work correctly from day one. There will be problems. And in large replacement projects, I've seen it take 6 to 24 months to bed in and resolve them.
For one telecommunications organisation, their system failed to automatically provision one of the three core services they provided, leading to it having to be done manually at additional cost. This took 12 months to resolve.
You need to assume problems will occur and treat them appropriately.
As such, we need to ensure that we are staffed adequately, both in terms of technical staff to resolve and operational staff to handle any fallout. And we need to treat this as a marathon rather than a sprint. If we are burning out our teams to hit a go-live date and then expecting them to continue that pace during any bedding in period, we are simply setting ourselves up for disaster.
Having teams work in that fashion will simply result in mistakes and ultimately larger problems.
At one client, they released a replacement system only to find bugs. The team were tired, but worked hard to attempt to fix those bugs while under significant management pressure. This pressure led to many mistakes - effectively compounding the original problems until they reached the point that the whole project had to be suspended.
In that instance, I advised them to revert to manual procedures and told the development team to take a few days off and come back with clear heads. This was not a message anyone wanted to hear, but it was the only practical approach.
And if the software product is customer facing, say for example, an e-commerce website, you have to expect some level of customer impact with a whole system change.
The risk is simply too great to assume otherwise.
As such, you should factor in any direct loss, such as a drop in orders, as well as any indirect costs to manage the situation, be that additional support staff or any customer compensation.
In this episode, I wanted to cover some of the additional challenges that the existence of an already working legacy system can present during a replacement project:
- It may need additional changes
- It may not be well understood
- It may be well liked by the users
- And often there are unexpected impacts of switching between them.
The creation of the replacement software in itself is like any complex software product - a difficult thing to deliver successfully - and these additional challenges only make it that much more difficult to achieve that success.
In next week's episode, I want to take a look at the third option for addressing legacy software - Outsourcing.
Thank you for taking the time to listen to this podcast. I look forward to speaking to you again next week.