Love Letter To Legacy - Gerald Benischke

Hello. I can't believe that so many of you voluntarily walked into a The doors are now locked, so you know, there's no escape. Um, we we only let people in. Anyway, I'm Gerald, and you've come to hear me waffle on about a love letter to Legacy. Now, first of all, yeah, I'm I'm I'm Legacy really. I mean I I remember Java 1 uh Java 1.0. That's how old I am. Um when lambdas used to be called and were anonymous classes. Who remembers that? A lot of legacy in here as well. Um yeah. So this talk is about me talking about legacy which I actually find quite exciting. Now let me let me explain why. Um what is legacy code? I mean if you've

paid attention to the news uh there was a a small breach of Oracle who decided that it's not the Oracle cloud that got breached it's the Oracle classic cloud. episode that was a master class in uh um breach notifications. Anyway, what is legacy code? Uh as I was talking to Rick before, he reminded me that uh Michael Feathers has got a very neat definition of legacy code, which is that code that isn't tested is legacy because if you can't test it, can't trust it. So I've been a developer by trade for quite a long time, you know, legacy. And when you get given a project not in a source code repository but as a zip

file, that's legacy code. When you look at the tests that are in there that cover about a third, but all of the asserts have been commented out. So they don't actually test anything. That's legacy code. So code without tests is legacy code. But I'd take that a little step further. I'd say that code without test that you can trust is legacy code. Because just because you've got a test folder and you know you press a button and you run it and it says green doesn't actually mean that you can trust those tests. If you've been given that zip file and if you've been entrusted with that and said right now make changes doesn't work like that does it you have to then

understand what the tests do and again I'll take it one step further code without tests that anyone can trust is legacy code it doesn't it it makes no difference if you can trust it because you know it's a legacy system. You're only going to be working on it for a year and a half and then some other um lower bidder will come along and look after the legacy system for you. I'm not bitter. I'm not bitter at all. Um some of you I mean I know we some work in security we tend to be quite observant. You might have noticed that I sneaked some classic cars in my previous slides. And classic cars are quite valuable these days. I

mean, if they if they haven't broken down and rust away in a garage. It's it's actually an interesting thing because sometimes people struggle to find a name for legacy because they don't want to call their legacy system legacy because it's it's a swear word, isn't it? I have to work on the legacy system. However, I've heard abominations like vintage systems or heritage systems and that's just ridiculous. But at the end of the day, going back to the the value, when you look at a lot of [Music] systems, legacy systems sit behind a huge amount of our daily lives. You wouldn't be able to do anything in government without some mainframe somewhere. You wouldn't be able to do

anything with your bank without some legacy system in there. Now, why is that? Cuz they've been there for 30 years and they've worked. That's actually not a swear. If something is really old, something's really old and it still works, that deserves some applause, doesn't it? You know, just because it's not the latest shiny. I mean, I don't know how the organizations that you're in work, but I'm sure a lot of you at the very back have got some legacy system sat there, or at least an organization that works with a legacy system that you really, really need. And remember, legacy doesn't just mean cobalt. Legacy can mean anything. You know, if you've got a 12y old Java code

base that nobody's touched for a long time, that's legacy platform. Another way of thinking about it is that complex code is legacy code or it will be the thing that you develop today is tomorrow's legacy code. Um, if you start developing using vibe coding like the cool kids these days, are you really going to add tests? Are you really going to understand those tests? Are you really going to trust those tests? So, you vibe coding instant legacy systems. Now, how's that for a for a use for AI? It'll keep me in a job for quite a long time, I'm sure. Um, so what usually happens when we deal with legacy systems, what usually happens is that somebody goes and I have

to be on support for this crap again. And you also can't hire for it because nobody wants to work with the legacy system. And there's metaphorical gaffer tape involved. Sometimes it's not metaphorical gaffer tape. One of my favorite anecdotes from working at HMRC is the anecdote about the Swansea data center that had a mainframe that got flooded where the floor gave way and the main frame was held in place by its network cables. So when they sent the contractor in to, you know, fix the floor and do the damage, undo the damage, they told the contractor, "No, no, no, you can't unplug those cables because the system is still working." So they had to build they had to hoist up the main

frame, build the floor underneath it, and then Yeah, it's funny how legacy systems can survive this kind of thing. And I think that's a really nice metaphor. Um I I call this I call some of the problems with legacy the maintenance death spiral. And it doesn't matter at which point you start you sort of going round in circles. You know you you end up with something that because you know you've been given the support of a legacy system you don't really know what you're doing. So you don't really want to touch it. because you don't touch it, you don't have any improvements. And because you don't have any improvements, inevitably all the people who deal with

it get bored and want to move on, which then means that you've got poor system knowledge. Because any massochist like me that works with legacy ends up kind of going, "No, I want to work with something else." So maintenance death spiral. It's a bit dramatic but you know um nobody creates legacy code intentionally. There is a there is a metaphor called Chesterton's fence where you have a fence that you don't know what it is. Now do you just tear it down or do you leave it there and try to understand what it's for? because the people who have put it there initially will have had a reason. A lot of the problems with legacy code is simply down

to the fact that people don't necessarily understand the context in which something was built. It's very easy to say, "Ah, this system is [ __ ] They didn't use this, they didn't use that. It's a horrible monolith." But put yourself into the position of when systems were originally created and things start making more sense. It's easily forgot. Yeah. Well, no comment. Um, you know, nobody wants to touch it. Legacy systems usually have got very old problems still in there. Um, and like Oracle found out, when you don't fix outdated software and leave it on the internet, somebody will pop it. Now, I want to step back a little bit. I want to talk about metaphors

because it's very easy when talking about legacy system to have this in your mind that legacy system are sort of brownfield development and when you create new software that's green field development where you have fantastic security pipelines where you have build systems that block anyone from doing anything that might be considered insecure. Well, cuz that's exactly how startups build their code, isn't it? Oh, wait a minute. No, it isn't. One of the things that you always find with Greenfield again, it turns into legacy because you need to build something fast because it's a startup and you you kind of think that you can cut corners and then you spend the next two years fixing all the problems that

you've created on that brown field. But in terms of the name of it, just when you think about the name Brownfield, you know, you don't want to go work in a dusty old coal mine, do you? You want to work in the sunlit uplands of shiny software architecture. I think that is a better metaphor. A cathedral. legacy systems, you know, the the big systems, they have survived for a long time. Okay, maybe some of the plans were lost in the midst of time because you handed over support to an external company, then you outsourced it, then you brought it back in house and none of the people who ever wrote most of the code are

still around, shall we put it that way? Um, some of the skills are sometimes not available. I mean, who who here knows what a war file is? You know what a war file is, Rick? Yes. But these days, we have monu uh microservices and things. We don't need war files anymore. When a legacy system needs a war file for deployment, the web archive file, sometimes you get problems that are like, hm, I don't understand what that is, so I'll just not touch it. Um, and yes, they did know what they were doing then. So, it's rubbish, isn't it? I mean, it's old. It's no steel, no glass. It's the cyine chapel. Um, just because something is old

doesn't mean it's bad. Just because something is old doesn't mean you can stick can't stick something modern in it. I'm coming to the place where I'm saying I think that when systems get modernized, you can you can unpick the complex code. You can you can add some testing to it. You can maybe you can't turn legacy code completely into non-leacy code anymore, but you can certainly build up a nice understanding and you can carefully make changes. Um, of course, when we talk about legacy development, that's what usually mean when you introduce a new pipeline. Uh, you have to you have the security pipeline and then something doesn't work. So, you just say, "Ah, we we'll we'll switch it off for a week uh

or a month or a year or forever." It's a problem with some of the things where you think you're putting in improvements and you kind of go, "Oh, I can just block stuff until the VP of sales says, no, we need this." Now, applies to general software engineering. You also have the alignment between development and security. often it's very easy for developers to to say ah I' the other year I heard developers saying when security tried to introduce a w um it's not that we've put the w in blocking mode we put it in breaking mode and everything every problem with the application was suddenly oh it's a w problem and vice versa security tend to

look at developers. These idiots don't know what they're doing. Um, it tends to work a lot better when you sort of align when you have some independence, but you're still pulling in the same same direction. Now, let's see. So, as you might have guessed, I have worked on some legacy code. Um, and that's what it looked like. Okay. We might recognize that this is from precoid times the you know the legacy way of working if you like um but the tr the the interesting thing was that we had a legacy system which a lot of you will have used because it's the like HMRC's way of paying taxes self assessment and that was said 12y old

Java codes that came in a zip file that you needed to work out what it did before you could actually try to maintain it. And we split things into three sort of swim lanes. Um, we dealt with all the books, but we also made improvements from new features and actually improving how it works. And it's the same thing for application security. If you want to make changes, if you want to improve things, you can't just say, "Right, we're stopping everything, putting a new system in." You have to make incremental improvements. Now, ult inevitably, the question comes up, should we just take this big ball of mud, this legacy system, and and and rewrite it because it'll be so much

better? you can probably guess what I'm going to say. You know, I mean, these are the things that people often say, "Yeah, we we need to rewrite it because then we can do it properly. We can consolidate our tech stack. Uh we'll bring in a new team to build it cuz that always works well when you bring in a new team to build something that an existing team then continues to maintain." Um I guess there has been something in the news recently that um yeah uh I think they said they were going to rewrite it in 6 months. Um yeah no I I don't I don't think so. Um I I don't think you should just go and say

we'll just rewrite everything. It hasn't worked forever. when Netscape was trying to rewrite their browser, uh they're replacing everything, um they basically then lost all market share to Internet Explorer because it took them much longer than they thought and the same story has been repeated time and time again. Now, I'm not saying that you can't ever get rid of legacy systems, but you need to look at them to sort of say, you know, where can you make the improvements? Can you make small improvements and phase things out? If you try to think of it as one big thing that you can just lift and throw away and put something new in, that will inevitably almost never work in my

opinion. Now I've talked a bit of legac about legacy and now I'm going to going to tell you what legacy gave to me. Um because it is something that actually I I worked at a a system. I I sort of hinted at the name HMC. Um and that was like 7 million lines of Java code and no one human being can understand everything that goes on in the code. So it is quite impossible to just sort of go and say right we can rewrite everything without understanding all the side effects. But digging into specific things and trying to work out all the idiosyncratices of of the system made me quite good at trying to read code and

find problems. In fact, it made me so good that I started finding security issues which then led me to change over into application security which was a lot of fun. Uh it also showed me that not all of the solutions are technical. Sometimes you don't want to go and say right we need a new piece of software for something a skill that I think we might be losing now that vibe coding is everywhere and which is create new tools legacy instantly. Um and I also found that when you can work in an agile way, which doesn't mean scrum, it doesn't mean Jira. I think Martin Fowler said that um agile is is very often uh confused with working in

sprints and having Jira. But if you can work in small steps with quick feedback, it is something that you can do whether it's a shiny new system or an established proven value old system. So yeah, what did we do in this talk? We sort of tried to define legacy. I my big invention is the maintenance death spiral. Probably not my invention though. Um language matters a lot when you talk about legacy system. If you if you go and work on a system and say it's a legacy system and go in with the mindset it's [ __ ] you're not going to see the value because you kind of go, "Oh, it's not the thing that I'm used to."

Um, don't just re rewrite it. And it can give you a lot of joy working in a legacy environment. And that's me. Thank you very much.

Great name, by the way. Love that. Um, we got time for a couple of questions. Absolutely. Anyone got a question? They'd be shy. We could be shy enough. Yeah. Do you think ultimately changes in standards that kill systems over time?

Oh, that's a that's a very good question. Um, it's it's sort of it's a tricky one because I mean sbombs are great for for asking questions because just because you have a a a dependency that somebody say there's a vulnerability there doesn't necessarily mean that you need to to fix it because it always depends on the context of of the way that you're using things. And I think uh one of the things that you find with with legacy systems these days is that most most of the time they tend to be surrounded by more modern front ends. Um so a lot of the things that in a modern front end you can't get away with sometimes if you if

you assess the risk you know this is on an internal network and you've secured it properly. That's obviously the a big if. um then you can still sort of decide well this system is providing value. This system is is going to give me a chance to do things. It might not be the thing that you turn your attention to immediately. One of the things that I would recommend to people who start out in software engineering is to learn cobalt because all the people who maintain the existing mainframes they're what 70 getting big fat juicy contracts because nobody else can understand it. um the idea that AI is just going to replace everything with complex systems

with millions of lines of codes and finding every intricate thing without hallucinating I think is wishful thinking. So the the the sort of yes it's a difficult thing to to to deal with a legacy system when in in HMSSE we was we were stuck with old versions of libraries old versions of framework that ended up not being supported anymore because so many things go out of support so quickly. But there was sort of open source things they worked. We sort of loved and caressed them and cursed them in the meantime. But it was something where we understand the the weaknesses and some a lot of the time when you look at vulnerabilities 95% of them I think um

Jerry Gamblin gave gave us the stats once uh 95% of vulnerabilities are never even exploited. So it is a question of if you just want to do here's my security pipeline and we can't have any CVEs. Um that's never going to happen with a legacy system. But I would argue it's also never going to happen with a you know shiny new system. I've not answered your question but I've spoke a lot so I think we're at time everyone. So, got any more questions? Feel free to chat to Gerald after. But thank you so much.