Optimise for continuous change, not modernisation or legacy | The Big Tech Debate
On 12th of June, Director of Engineering Jacob Clark was invited to put forward an argument against the motion that “Modernisation is overrated – legacy applications still deliver” at The Big Tech Debate.
Thank you to MRJ Recruitment for the invitation and thanks to Anna Rebecca Aitchison who put forward strong points for the ongoing value of legacy systems.
Below you can read Jake's argument or you can watch the debate on YouTube:
Summary:
- Legacy systems lack a universal definition and mean different things to engineers (code they didn't write), architects (non-strategic systems), and executives (products without market fit).
- Most people incorrectly define modernisation as complete rewrites, which historically fail (citing Netscape's failed browser rewrite that cost them market dominance).
- Organisations should optimise for continuous change rather than debating legacy vs. modernisation, building systems that are inherently adaptable and replaceable.
When I think about modernisation and legacy, I think first of all modernisation is everything and it's nothing. Half of the problem is legacy doesn't have a well-defined definition of what legacy actually is. If I asked everybody in this room, they would come up with a different definition of legacy.
When I think about what legacy is, I think it is software that is either hard to change or costly to change, or the people who could change it don't want to change it.
There are probably three reasonable definitions of legacy code or legacy systems in general, and if you delved into the personas of different folks within an organisation (engineers, architects, and even VPs and executives) each one of those people would have a slightly more nuanced view.
You know, an engineer might say, "Well actually, legacy is just something I didn't personally write or the previous team before me wrote it, or I just don't like the flavor or the style that that code was written in, so it's legacy to me”.
An architect's view might be, "Well, this subsystem or this API is not on the strategic roadmap for the business in the next three to five years. It's going to go away, so to me it's legacy and I'm just not going to make a case for investing in that piece of software anymore”.
And to an exec (a finance leader or maybe even a VP of engineering) I think their definition of legacy would be, "Well, it's a product tower, it's a product stack that just no longer has market fit anymore, and actually we're pivoting to a new business or to a new market sector or whatever that might be."
Half the problem with legacy is that it just doesn't have a great definition. But if we boil it all down, it's just stuff that we don't want to change or can't change or don't have the capital to change.
I think modernisation has the same problem as well.
Modernisation is very loosely and poorly defined. I think if I did a survey in this room what modernisation means, I think most people would say:
"Well, it's a rewrite. I'm just going to take all of the problems of this existing software, I'm going to forget about them, and I'm going to pretend that I'm going to do a good job of rebuilding it in a new tech stack that's using all the nice new frameworks or whatever it is, and I'm going to do a good job of bringing over all the requirements. I'm going to solve all the performance issues and I'm going to ship the thing."
And that never ends well.
There's loads of really good examples, and I feel like I'm actually arguing both the for and the against here, but I'm going to get to a good thesis in a second.
Rewriting is not good. You look at Netscape - I don't know how long ago it was, 10-15 years something like that - Netscape decided in version three that they were just going to rebuild the whole product from the ground up.
They were going to rebuild the whole browser engine and the whole browser into version four.
It never came to fruition - well, I think it did eventually come to fruition, it just took them a long time to get there. And all the while they were losing significant market share. You know, there were these other browsers that were coming out that were doing a much better job and were able to get there much faster than Netscape was, and obviously Netscape is now completely obsolete.
So therefore, I think my argument here is that legacy is irrelevant. Modernisation is irrelevant.
Actually, I think what we are talking about is change and the optimisation within an organisation to be able to change continuously. And for me, that's what modernisation means, and that's why I am against this idea that legacy applications don’t deliver, because I think they do.
Legacy applications obviously deliver. They are paying your salary, they are likely generating revenue. If they didn't deliver, they wouldn't be in production. You wouldn't spend money on something that wasn't generating revenue or delivering business value. You would get rid of it, right? You’d throw it in the bin.
This leads us to the point and argument that I would like to make: that actually organisations should be optimising for change.
They should be optimising for the ability to adapt and the ability to either refactor, and I mean refactor software to be adaptable and to be changeable, or they should be building new software with that need to change, in mind.
And actually, in the minds of the designers as you're building a new greenfield piece of tech, you should probably sit there and say, "Hey look, in six months, 12 months' time, this thing that I'm doing now is probably going to be commoditised by somebody else. It's going to be somebody else's business, and if it isn't my business, then it should be easily replaceable." Right? And that's what you should optimise for.
And there's research around this. If you look at the DORA reports, they have this spectrum of teams, and it goes from low-performing all the way up to super elite teams, and it says the most elite teams are the ones that change the most often. They change their software the most often, and as a result of changing that software the most often, they have fewer failures and they're more resilient to bouncing back whenever they do have a failure.
And I think the reason for that is ultimately they've optimised for change.
So I think my core argument is: modernisation really is a synonym for change. We don't want to aim for optimisation because I think that ultimately ends up in messy rewrites, and I don't think we want to keep legacy hanging around either.
I used to work for a large organisation, I won't mention who it was, but they had pretty healthy revenue. I think they were about a $50 to $60 million business, and they got themselves stuck in this route where they would build a product, it would serve a market need, they would figure out that there was a slightly adjacent market need that they also wanted to serve, but they never built the software initially with adaptability in mind.
So what would they do?
They just built another product.
A complete replica of the existing stack, and then they would ship it to market. They did this six or seven times until it got to the point where their revenue was about $50-60 million and their overall technology spend was $20 to $30 million, which is a significant cost of goods sold just for the technology labor and opex that you're spending against it, which is kind of nuts.
But they got to the point where, yes, the business would argue that those six products were legacy because they didn't want to change them and there were these new markets they wanted to go after.
But because they were cannibalising both their opportunity and their capital to go after new opportunities, they were just stuck.
And yes, they were legacy products, they weren't modernising, they weren't optimising for change, but at the same time they were holding on to all these legacy applications that were destroying their market growth.
So that’s my argument: optimise for change, don't optimise for legacy or modernisation.
