Legacies | The Wrap-up

  |  Compiler Team  
Développement professionnel
Histoire de la technologie

Compiler • • The Wrap-up | Compiler: Legacies

The Wrap-up | Compiler: Legacies

About the episode

Over the course of the series, we’ve learned how tough it is to choose between older systems and newer innovation. Tougher still, is how those systems can make the people maintaining them feel: Frustrated, isolated, and stuck in the past while the world moves on.

As we wrap up our discussion on the topic, we hear from technologists on how they reconcile the old with the new to advance their understanding of their discipline— and maybe further their careers in the process.

Compiler team Red Hat original show

S'abonner

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcription

Nobody expects your iPhone to last 20 years, right? That's Bob Charette. He's a consultant and a contributing editor at IEEE Spectrum. He's one of the many people we spoke to when we started doing work on legacies. In one of our conversations, he started talking about the systems on submarines. A submarine is different from a cell phone, as you could imagine. The technology is a closed system, it's self-contained and that's by design. And different systems on a submarine do different things, and they're not integrated with each other. That's also by design. And since these are large machines that often are in remote areas, they can go a while without an update, think decades. These things were designed ... People thought, well, they're going to be there for 10 or maybe 12 years, but they're there 30 years, they're there 40 years. How do you modernize something like that, and how do you maintain it? Those are some heavy questions for people tasked with doing the work. Meanwhile, their friends over in the enterprise are working on the latest and greatest, new platforms and technologies, exciting stuff. Legacy systems can make an IT professional feel isolated, kind of like being in a submarine, deep in the ocean, away from everything, standing still while the world moves on without them. How can we fix that? This is Compiler, an original podcast from Red Hat. I'm Brent Simoneaux. And I'm Angela Andrews. We go beyond the buzzwords and jargon and simplify tech topics. Today, we're wrapping up our series on legacy technology. To listen from the beginning, start from the episode, In Defense of Legacy. Let's kick things off today with producer, Kim Huang. Brent, Angela, we've established over the course of the previous episodes that legacy infrastructure is sometimes left in place because of human factors. Let's bring back Jim Hall. We heard from him in the first episode of our series. Jim worked as a CIO and as a consultant in the U.S., sometimes at the state government level, and he says, "When it comes to keeping modernization top of mind, things can get a bit complicated." In government, the funding model is based on your tax levy, so it's how many residents do you have? How many businesses do you have and what taxes are they paying? This tax money really should be going as much as possible to benefit the public good. There's no point in gathering these taxes if they're not going to go back in some way to benefit the resident, building roads, repairing roads, bridges, infrastructure, things like that. So many of these IT departments are really responding to the here and now, and then it becomes really hard to then think down the line. And that has a trickle down effect on the systems, the networks, and the applications keeping everything running. That infrastructure is important. It's just not a priority, not compared to everything else. That's sad. Yeah, I know, right? It's easy for us to see this. We work in the tech space and we know the cost of modernization. We know the cost of the cost of things like technical debt, but people that are not focused on that, they're focused on keeping roads open, and making sure that schools have enough resources, and parks can be open for people to enjoy. It's easy to see how tech can take a backseat to all of that. Yeah, I can kind of understand that side, which is like if it still works, what's the problem? But then it works until it doesn't. There you go. There it is. Okay. If you are responsible for your constituents' personal information or the services that they need to do to go about their lives on a daily basis and they're running on ancient legacy hardware software and there's a breach, what do you think that does to your constituents? So kicking the can down the road in this scenario, it's never a good idea. I know we think of it as an afterthought, but if we just keep security, and compliance, and data security in mind, I think people would think about it a little differently and give it as much weight as it deserves. That's a really good point. I agree with that completely, Angela. And Jim, for his part, he says it's really hard to get people to think like that. It's not until something is a problem that people see the problem. But I think that these small and often understaffed IT departments at the state level, they see the need maybe for new technology, but it's hard to get them on board, and it's even harder to get a government official who's not touching that technology at all and who's often making decisions on budgets and spending. So as a result, people didn't feel the impetus to try something new all the time, and so when that happens, technology starts to sort of stagnate a little bit, and that was my experience. I'd like to ask these government officials, do you have the latest iPhone? What kind of technology do you have in-house? Do you have a smart house? Do you have a smart refrigerator? I bet you these folks are using new technology left and right, but not even considering that their towns and their towns' systems infrastructure deserves the same type of weight. I bet you they're all walking around with iPhone 14s, but what operating system are you still running the city's website on? They can't answer that question. Windows XP. Oh, man. We went there. We went there. Shots fired. But now, hold on, because over these past few episodes we've been talking about the value of legacy technology and legacy systems. Yes. But now we're talking about modernization. What's the deal? There are some systems that are just rock solid and by themselves, that's not a reason to get rid of it just because it's old, because it's still performing. But there is an issue about who's going to maintain it, right, there's the knowledge problem, the knowledge gap problem. And so some systems need to be replaced because there's just simply nobody around or very soon there's going to be nobody around who knows how to maintain it. And that is the real issue. That's the rub. One that our listeners probably already know. The technology isn't always the problem, the people who have the skills to maintain these systems, the humans, are aging out of the workforce. And the constantly changing tech landscape means the amount of people who have those skills is dwindling. So organizations are being presented with a tough choice, balloon their budgets with low priority modernization work, or maintain what's in place until there's no one left to do so. Lose-lose. Oh, I would not want to be in that situation because like you were just saying, it's a lose-lose. It feels like you can't win here. Time may make the decision for you in this case. And it's not just general knowledge that's on the line. Here's Bob Charette from the top of the episode. Sometimes it's a limitation of the technology itself, the limitation of the hardware, limitation of the software, but some of it is because that was experience that was gained in how to actually make this stuff work. People have shortcuts or they'd find there were a lot of times that the people had used these undocumented instructions and now you're trying to say, okay, well, how do I accomplish that with that instruction that's not supposed to be there. And in some cases the hardware manufacturers actually allowed them to stay and made them document it. So you work on a system long enough, in this case, Bob was talking about the submarine systems that he worked on back in his career. You become a living document of its many quirks and unfixed bugs and additions, and some people like that. Angela, we've talked about this before on the show where- Yes. Yeah. Oh yeah. ... you have someone who's worked somewhere for so long that they're like a walking, talking documentation. All up here. Some people like being like that, but if you don't count yourself among them and that's not your ideal job, that's not what you want to be, it can be tough, especially considering how many people break into IT in the first place. All right, everybody wants to work on the new thing. People who work in maintenance are often looked down upon by their peers while you're working on maintenance. Yet, without those operating systems, your business goes away. And at the same time, lo and behold, almost every undergraduate who comes out of a computer science or computer engineering course of study ends up working in maintenance because that's where the need is and that's where the systems are. No matter what, it seems. I think you do have to have an understanding of how things work and the underpinnings before you go on and want to do the new, the next the new, the next the new. We talked about this on the Frameworks episode, where you really don't want to jump into frameworks because you don't know how the language works underneath. So if something breaks, you really don't have an understanding of it. And I think there's a lot of weight in taking that step back and understanding- I hear that. ... how things tick before you jump into it. For me, I feel like there's two things happening here. There's that person who's coming into their IT career who is being tasked with maintaining this older system or maybe older hardware, in this case. We talked about hardware in the series too, and they want to work on the new and exciting thing, not just because it's new and exciting, but that's where the majority of their learning, their education was. They got taught the latest and the greatest because, as we've talked about in previous episodes, there are many places in academia where they just don't teach about these older programming languages, older systems. It's just not taught anymore, so your expectations are kind of off and that's what leads to that feeling of being left behind or isolation. You're being stuck in a basement with a bunch of old dusty servers while your friends are out there living the life, working on the latest development tools, frameworks, all of that. That's what I feel like is going on here. I wonder, how do you come to terms with that if you are new in technology and you're longing for the opportunity that your colleagues are having? But if we think about it, we all have to start somewhere, especially if you're trying to get into technology. I think any foot in the door is a good foot in the door and then you can make your way from there. So I wouldn't discount those beginning jobs. And sometimes they seem a little mundane or you're not doing all the cool stuff, but it matters. It matters in the company that you're working in. It matters in the grand scheme. So if you think of it that way, your work matters and it's an integral part of what's going on there and you can use that experience to take it wherever you decide to go. I think that you're onto something, Angela. Maybe it's just a matter of reframing the situation. I wanted to hear from a younger technologist who had these experiences and we're going to hear from her next. My name is Olivia Huang. I'm part of a site reliability engineering team in Red Hat called App SRE, and we manage Red Hat SaaS services that run on OpenShift Dedicated. So we were talking about reframing the conversation around legacy technology, and I spoke to Olivia here about her experience in academia versus her first actual job. As a side note, I just want to say we're not related. Thanks for clarifying, Kim Huang. No problem. As school you get exposed to mostly cutting edge technology, the newest possible, and you learn all those theories about the process, the software engineering process. You got the impression that it's all figured out and kind of perfect in some way, but after I joined the industry, I quickly found out that's not the case. How surprising is this? Not at all. Not at all, I would say. Not at all. This is the real world. She even uses Red Hat itself as an example. Red Hat is special in we use Kubernete or OpenShift extensively. Containerization is a norm for us, but when I just joined the industry, I found out that really many, many companies don't use Kubernete. Their code hasn't been containerized, even though they're thinking about it, they see this whole journey as a very difficult and lengthy one. So I wanted to ask a question because I feel like it's really important. Can understanding the why behind legacy software, legacy infrastructure, can it make technologists better at their job? Can it make them understand customer challenges better? What do you think? The answer is yes. Does it help them understand their customers better? Yes, because not every customer you come across is going to be cutting edge. They're still trying to work out- I would say most, right? Yeah, they're still trying to work out there app modernization formula. Yeah. It's hard to go from the way that you've run your operations for a really, really long time and refactor and rejigger into something totally different. There's this huge chasm of education and information that needs to be bridged before you can get to the Kubernetes and the containerized applications. And we at Red Hat, we get to see that our customers sometimes struggle with that. You have to understand, meet your customers where they are. There is a pathway, you just have to show them this is how you do it. It's not easy. It might not be glamorous, but the end result is what you're looking for. I would also assume, and Angela, you can tell me if this is correct, but that it's not like an on-off switch. It's not. Where it's like you flip a switch and it's like, oh, modern architecture. Exactly. Or whatever it is. It feels like there's probably like a relatively slow evolution towards more modern. It is piecemeal. Yeah, it's piecemeal. And you gave to inch along. You do the low hanging fruit, you test, you see if it works, and then you bring more and more along. And there's a lot of learning. There's a lot of training that has to happen. You have to retrain yourself. You have to retrain how people think. You have to retrain how people do their work because moving into this modern application development world might be a whole site different from what you were used to. If you were doing waterfall and it took forever for things to get upgraded and you're trying to do things with modernized application architecture like containerization. Well, things move so fast. The whole pet versus cattle thing, you really have to understand that you don't have to be wedded to this. It's okay to move forward. And that is a whole mind shift and your organization has to be ready for that mind shift, ready for that transformation, and it does take time. This is always something that I've wondered about, Angela, do you ever actually get there? Is it the case that maybe the goalpost just moves farther out every time? It's still moving. Yeah. It's still moving, but that's okay because that's what technology does. It's constantly evolving. Most of us aren't on the bleeding edge, we're just trying to again, maintain, keep the lights on, make do with what we have. But you're right, the goalposts are constantly moving. You just can't lose sight of them. That's the thing. So Olivia understands the challenges companies face when updating applications to both of your points. And migrating to platforms as well, she's learned this lesson in a very short amount of time. A lot of software and a lot of application need to be running at real time, meaning you can't really take it offline, say a day or two and refactor or use a different technology to replace it, which is not realistic. And when you think about having to actually do a migration instead of shutting it down and getting it ready, then turn it on, the migration is way more complicated. Every industry is different. Every company is different in their journey. So just like you said, it's not just an on and off switch. She said it. It's a journey. And the journey is different for everyone. Of course. Exactly. How do younger IT professionals ditch these feelings of being left out or being left behind? Maybe as what we were saying before, it's just a matter of reframing the conversation. Even though there are new technologies, there are fundamental pieces about computer science and networking operating system is so fundamental. It really hasn't been fundamentally changed for a long time. And understanding why an older solution is in place can go a long way. I would say try to keep an open mind and be empathetic because there is always a reason for a legacy technology or code to exist in the first place. Try a little bit to understand the why and how it got there, that way you learn more than just look at it and say, this is a way too old, way too not excited for me to learn from. Yeah, she nails it. She's right. She does. And I will have to say that it's not just young IT professionals, it's people who are pivoting into our space- That's right. Oh yeah. ... who are learning these new technologies and maybe whatever sector they came from, they're used to using technology X and they're coming here and learning this new technology Y. And they get their first job and it's like, "Hey, wait a minute, this is not what we learned in class. What are we doing here?" So we have to understand that sometimes you do have to take that step back and say, not everybody ... maybe where they worked before, they were used to using legacy technology, so they kind of understood it to a certain extent, and you have to bring that with you. And there is a level of empathy that we all have to have with these organizations, that they don't want to be here. There are a lot of factors and if we can appreciate that this is where we are now, we're trying to make steps forward. Understanding the older technology is always key because that is always the foundation for what's moving forward. If you don't know that, you really don't have a great grounding in the modern stuff I think. It's a good point. So I wanted to bring this up too because over the course of the series, Johan and I have really struggled trying to even define what constitutes legacy technology. What is it? I remember that. What counts? What doesn't count? And Olivia also has this struggle. We look at some of the so-called legacy technology today, it was merely released maybe 10 years ago. That really isn't long enough to call it legacy. Things are moving that fast. Yes, they are and it's going to continue to multiply. If we think about how small hard drives were back in the sixties, we look at where we are in 2023 and it's like, wait a minute, that's 4 terabytes on this little thing that you can stick inside ... So it is moving at such an exponential pace that just because it's 10 years old doesn't necessarily make it legacy. It is still functioning in spaces and there's innovation happening on these types of platforms, as well. So age is not the determining factor, I will say. Yeah. Yeah. Yeah. And no one can predict when the new thing becomes the old thing. Nope. It's going to happen though. It will happen; it's just a matter of time. Even though you might introduce a new technology to replace this one, you might have to do it again in five years. Ain't that something? I'm laughing because it's true. It never stops. Once you think you understand it, you got your hands wrapped around it, something else is going to come along and you're just going to have to learn the new stuff all over again. Even in my spaces where I'm working, I'm not specifically working in code, but I'm working on these different platforms and tools, I feel like every 3 years it's like a new word comes up. And I'm like, huh, what's this? And then I have to learn it. I have to at least know about it because people are asking about those skills and asking if I have those skills. So it's not just people who are developers and programmers, it's also people who use these platforms for other things. Exactly. You have to at least know about it and it could be very overwhelming. I want to bring back Bob for some parting words. In his view, it's important to understand that the right tools don't last forever. Legacy systems are an important part of our IT ecosystem. And we need to think about how they can create new opportunities and when the time has come for them to be retired, we need to retire them and we need to move on. The idea would be if we really could build systems that were—in essence—throwaway systems, systems that we could build, they had a very finite life, say 7 years, 10 years, and we captured the data and we could capture the functionality—and AI might be able to help us do that—then, we wouldn't have this issue because we could continually refresh them at an economic rate. Know when to hold them, know when to fold them. Know when to fold them. Know when to hold them. If only you could know though. Yes, if only you could know. It's not that simple, but he does have a point. It's also important though, for technologists to have empathy and to form an understanding of these legacy systems, these languages, and tools. For Olivia, that understanding is important to move forward in one's career. When you learn to treat some of the process and some of the code as a black box, you'll find this industry not as the mistress and you get to learn a lot more. And this is really something to serve you, to serve your creativity, and your day-to-day life productivities. It doesn't have to be this intimidating thing; it can be for everyone, and it is for everyone. So Kim, Angela, this is the last episode of our series on legacy technology. I'm curious how both of you are thinking about legacy technology now. Angela, do you want to ... Well, having worked with legacy technology in the past, I have a respect for it. I know that you have to understand how it works, especially when it's your responsibility to make sure that the uptime stays where it needs to be because people are utilizing these systems. It's important to the business and that is your job to understand it, make yourself familiar because it is now your responsibility. Of course, in that, you have to figure out, well, how do we modernize this? Is there a way to modernize it? And sometimes that answer is no. Yep. Sometimes it's maybe. Sometimes it's flat out, oh, of course we can move forward. But if it's your responsibility, you have to figure out is it something that we have to deal with, if so, how do we make it resilient? How do we document it so people know what to do with it? There's a lot that goes into supporting all types of systems, but we're specifically talking about legacy. You want to make sure that the system is not left behind, that no one forgets about it, that it gets its updates, that it gets attention, that people know how to access it, and use it. And documentation is key. Yes. You can't keep it all up here in your head. Don't be a living document. Right, like some people are want to do because they consider that to be job security. But if that app goes out and you've decided to be this silo of information, and now they're not using it anymore, then you've probably just made yourself obsolete. So automate the things, figure out the things, document the things, and do your best. I think you getting familiar with legacy technology, if it's a part of your job, take it seriously. How about you, Kim? How are you thinking about this now? Well, I feel when it comes to legacy technology, sometimes it's a matter of recognizing it and navigating around it. Other times it's understanding the past while embracing something new, meaningful change, just not change for change's sake. What's important to remember though is that human element, it all depends on people communicating with each other, sharing their knowledge and experience, sometimes through documentation with the generations to come, and embracing both the lessons of old and the exciting potential of what's next. So what did you think about this episode? We would love to hear your thoughts. If you're catching this in the middle or somewhere, go back to the first episode in our series, In Defense of Legacy. What do you think about the use of technology—legacy technology? Just hit us up on our socials at Red Hat. Use the hashtag #compilerpodcast. We'd love to hear what you think about it. And that does it for this episode of Compiler. Today's episode was produced by Kim Huang and Caroline Creaghead. A big thank you to our guest, Jim Hall, Bob Charette, and Olivia Huang. For Victoria Lawton, podcasting is all about the public good, building playlists, sharing memes, things like that. Our audio engineer is Christian Prohom. Special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta. Our audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Nick Burns, Aaron Williamson, Karen King, Jared Oates, Rachel Ertel, Devin Pope, Matias Faundez, Mike Compton, Ocean Matthews, Paige Johnson, and Alex Traboulsi. If you like today's episode, please follow the show, rate the show, leave us a review, and share it with someone you know. It really does help us out. Until next time, thank you. Bye. All right, we'll catch you next time.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Article de blog

Friday Five — August 15, 2025 | Red Hat

15 août 2025  |  Red Hat Corporate Communications

...

Article de blog

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

14 août 2025  |  Brian Stevens

...

AI inference

About the show

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.