Legacies | In Defense Of Legacy

  |  Compiler Team  
専門能力の開発
技術の歴史

Compiler • • In Defense Of Legacy | Compiler: Legacies

In Defense Of Legacy | Compiler: Legacies

About the episode

As the tech industry continues to innovate, more technology gets classified as outdated—often referred to as legacy. But younger IT professionals often start their careers working on legacy hardware and software, and upgrades aren’t always an option. How can they learn and grow, while still working on older tech?

This episode is the first in our new series, “Legacies”. We tackle different examples of older hardware and software, break down their relevance to today’s industry landscape, and help junior tech workers connect the “old guard” with their own career journeys.

Compiler team Red Hat original show

購読する

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

トランスクリプト

It is never actually going to go away. I know a lot of people say we are going to sunset this, that and the other. Right? That's Jessica Cherry and she is sharing some hard truths about working in the tech industry that a lot of people probably don't want to hear. You're going to work with legacy technology whether you'd like it or not, so you may as well learn about it. SunOS still has paperwork out there—tape system. Tape system still exists for the nuclear stuff because you definitely can't hack that. It's not going to go away. It is better to learn and rather than pretend it's not there, right? In the next several episodes of Compiler, we're diving into the world of legacy technology, which as it turns out is an indispensable part of our world. We're going to cover so-called antiquated languages to hardware that may have started running before you were even alive. All of them have their place, for better or for worse. We're going to try and convince you that more often than not, for your career, it'll end up being for the better. This is Compiler, an original podcast from Red Hat. We're your hosts. I'm Angela Andrews. And I'm Brent Simoneaux. We go beyond the buzzwords and jargon to simplify tech topics. Today we hear why working on legacy technology could actually be a good thing. Producer Johan Philippine is here to tell us why. Today's episode is a broad defense of working with legacy technology. First, let's poll our hosts. Brent, what do you think about when you hear the term legacy technology? When I think of legacy technology, it's like the thing in the closet that's all duct taped together and no one really knows how it works, but its just in the closet humming along, it just works. And don't touch it too much. Don't touch it. Angela, what about you? When I think legacy technology, I think punch cards, five and a half inch floppies, zip drives, a server in a closet that is covered with coats and dust and whatever else, and it's still running and no one knows why, but you better not touch it. We've all seen those, haven't we? Mm-hmm. What I'm hearing from both of you is that old technology clearly fits in this definition of legacy technology, right? What Kim and I have been kind of stumbling into while doing our research for these episodes is that there's no clear line you can draw as to what is and isn't legacy technology, right? How recent can we go in terms of the newest "legacy" technology? We couldn't find a formal definition anywhere, but we're going to need to work with something for these episodes. So here's what we're going to define it as. Legacy technology is hardware, software, or any technology system that is "outdated," which to me means that there's likely a newer alternative or its use has been phased out entirely. Oh, okay. Now Angela, what's been your experience working with a legacy system? I have a lot of experience with them because I've worked in smaller colleges and smaller companies and there's always been this system that is really outdated and should have been updated or upgraded months or years ago, but it's still chugging and no one knows why and you can't touch it. And working here, I find that when you come across folks that are still running older versions of a software, they have really good reason to still be doing it because there's something that's running on it that is just so mission-critical that it cannot be touched at the moment. It cannot be containerized. It cannot be modernized. It could be the language that's running on top of it. It could be a myriad of reasons, but I've learned that although my knee-jerk is to be a little like, "Oh, poo poo," but now it's understanding that this is happening for a reason and you have to understand that we don't want to stay in the past, but sometimes we have to. One thing I've heard from a lot of technologists is that legacy technology is very pervasive. Has that been your experience too, Angela? It is. I hear it more and more now that I'm an SA [systems administrator] here where folks just can't move off of something and we want them to because it's for the security reasons, it's for the feature sets. But there's something in their environment that doesn't allow for that and we as technologists, we have to respect that. Yeah. So Johan, tell me if this is right, but chances are if you are starting your career as a technologist, there is a good chance you are going to come into contact with some legacy system. Mm-hmm. That's what we've found. That's what we've heard, and it's something that a lot of new technologists, people who are new to their technology careers, they see this as something to dread, right? They think that I'm going to get my first job and I'm going to be stuck working on something that's super old rather than working on the latest and greatest kind of stuff. There's a perception out there that working with legacy technology is going to be a drag on your career. It'll slow you down and allegedly prevent you from getting good jobs down the line because you're not getting experience with the latest and greatest technologies that are building the exciting applications and things like that. We've seen it countless times all over the internet, especially from new grads looking for advice on how to make sure they don't end up stuck working on older technology. Jessica Cherry, the infrastructure engineer and open source technologist that we heard from at the top of this show has a very good reason why trying to avoid legacy technology is not a realistic goal. I have had this happen at every single job, dude. Yeah, I have been hired to do stuff that was not anywhere near my job title. I show up for a job, do the interview, "This is what you're going to be doing." What I am doing is completely different than what I was told I'd be doing. I have been handed stuff that is just, "Here's a black box, have fun." Here's a black box. And that black box that she's referring to, those are systems that no one else wants to work with because it's old, because there's little documentation and it's often not something that early on in your career anyways you've worked on before. So you're handed this black box and you've got to figure out what it is and how it works because at this point it is part of your job, and switching jobs might just mean getting handed another black box right at the new place. Now, one quick caveat, she later elaborated that a lot of the times when she's starting a new job, she'll have a host of things that she was told to do, and on top of that, there's this other black box that she's handed that she needs to work with as well. They're not going to put that in the job description. No. Right. They're not going to put that in the job description. Most reputable places anyways. They're not going to hire you and then completely change your job to something different, right? Hopefully... Oh, Angela rolled her eyes there. Oh boy. Sounds like there's a story there. There's always a story. Okay, so you get this box, you get this box, what do you do with it? What is Jessica— You log into it and see what's on it? What else are you supposed to do? Hopefully they still have the credentials. Usually they do. It's on a sticky note taped to the side of the server because again, no one knows what it does. So you have to log into it and see. You have to get the lay of the land. You have to understand exactly what this— How do you do that though? You click around. Now we Google, we figure out, "Oh, what's the software called? Well, what does it do?" Or we look at the network traffic. Well, where is it going? Who's accessing it? Check the logs, what's happening on here? You have to get an idea of what other things are installed. If there's any services that depend on one another, how it all works, and you just try to make a map of what this thing is doing and understand who its stakeholders are. Maybe you go talk to them. Maybe they have some idea. You have to start somewhere. So the first thing you do is you log in. That can't be the only thing though, right, Johan? Yeah. I mean, if you're really, really lucky, you have a Paul. Paul is your single point of failure. Paul knows everything. If Paul gets run over by a bus, you have a problem. I'm going to call the name out as Paul because I had a Paul, right? You become friends with Paul because Paul knows everything, and that makes your job a lot easier to hang out and be like, dude, can I just write notes and hang out with you for 15 minutes, please? I've known a Paul. I have been a Paul, so... I have a Paul in my life right now too. They're invaluable. Don't let anything happen to them because yeah, you wouldn't know what to do. If my Paul ever leaves, we're done for, we're just done for. Everybody should have a Paul. Mm-hmm. Yeah, hopefully. In the best case scenario, you have a Paul who will teach you about the black box, and at some point down the line you'll teach someone and they'll teach the next person. It keeps the system alive and running and the business operating, but you're still stuck with that hit by a bus problem. So what do you do when you don't have that unbroken chain of knowledge to pass on the sacred scrolls? Jessica has found that she can figure things out, much like Angela was just describing though, it'll probably take a bit more time and be much less pleasant. Sometimes I just wander around and look at stuff. It's good to have the general interest of what's going on here. That has always been a little bit of my life in general where I'm all like, "I wonder what happens if I touch this," and my mom will tell you, this poor girl just will fall into a lake to see if it's wet. And I am that person where I'm like, poke, poke. "Oh no, I blew it up." And then have to... Which is my buddy nicknamed me Armageddon for this very reason. I will blow stuff up and be like, "Huh, I'll figure it out. Hold on, I'll bring it back." And that kind of skillset is useful. So Angela, just like you were telling us a few minutes ago, you log in and you try and figure out— Have a look around. ... who the system is talking to and what it's doing, and you start poking here and there and just figure it out. You just figure it out. And her example, some of her pokes are dangerous. I try not to take such an approach. Well, We had an episode about this, right? Oh, we had two. I'm not that adventurous and they were very good ones. But we've all been that person who just wants to poke the bear to see how something works, and it's not always the best idea, but she's right. That is an amazing skillset to have to try to be resourceful and figure things out and to rebuild and make it make sense. So her skillset, it's invaluable, and I like the fact that she goes into these black boxes with that type of curiosity. Yeah. Taking down the test environments can be very, very valuable and good learning experiences. Just try to make sure you're not pushing the big red button on the production environment. What does this do? What does this do? Oh, uh oh. We've all been there. Yes. What episode was that? Big mistakes. Big mistakes. Part one and part two. Make sure you go back and listen so you know the private joke we're laughing at. Now, we talked about what legacy technology could be. Sometimes it's a server that's been running for a long time, but it works and if you touch it, some crucial part of the business no longer operates. Sometimes it's a pet project with relatively recent technology but hasn't been regularly updated and is now a liability, but getting rid of it might have political ramifications in the office. There are a lot of potential reasons why even technology that people ideally would want to update ends up sticking around. Sometimes it's money, sometimes it's skillset. When you have something that's been sitting there for longer than I've been alive, you're not going to have a lot of people who have the capabilities to do that, right? I'm sure that our listeners, there are a lot of people out there that they work with who know that they're the people. They know where the bodies are buried, and those are the folks that you always want to keep on your good side because they're going to help you out in these types of situations. So be nice to that person because there are some folks who know the history and know the story of an organization and how things work and the ins and outs. And maybe there's no formal documentation, but sometimes there's these mental runbooks up in people's head that they've kept for all these years and maybe asking the right question could be of use. So Jessica has taught us a bit about learning to deal with legacy technology because you are going to need to deal with it at some point. Our next guest is going to share why it's a good idea to learn about tech history. We spoke to Jim Hall, who's primarily a tech consultant. He also leads trainings and workshops and teaches part-time about the history of technology. And he puts a lot of emphasis on tracing the origins of modern technology to its roots. It's how we got from there to here, and if you kind of understand those milestones are going to happen along the way, you understand the stuff that's around us today because it didn't just appear out of nothing. So it came from somewhere. So where'd it come from? We had a really long conversation with Jim about this specifically, and he shared a lot of insights about how the technology we have today is built on the technology that we had yesterday or the year before. It's the whole idea that we are standing on the shoulders of giants. Where we are today is thanks to all of the technology that existed in the past. His classes are an introduction and typically not taught to computer science majors and the like, but he thinks that they're missing out. There's some concepts that people kind of forget in a modern context that I think that it would benefit them to know something about that history. So for example, when people graduate, when people go... Computer science students, when they go through the programs today, they're learning modern computer programming languages. They're learning about modern methods because that's what you teach. It's 2023, you should be teaching modern concepts, but when they graduate, they're likely to experience some older technology. I don't think it's likely that anyone's going to find FORTRAN today, but COBOL is possible. Teaching COBOL in great depth would probably take away from some of the other skills-building classes that computer science majors have. But having a working knowledge of the tech would give them a headstart in some of the situations that Jessica shared with us. Jim was telling us specifically about COBOL and how there's a lot of parallels between COBOL and Python, right? Python is this huge language that a lot of people use these days, but apparently structurally the two are very similar. And just knowing that can give you a heads up and learning how to use COBOL and program with COBOL and interface with it when you're faced with a legacy system that runs on COBOL. So in the beginning of the episode we were talking about how legacy technology, it just exists. It's pervasive. You're going to have to work with it. What I hear you saying now, Johan, is that it's not something necessarily that we should just kind of deal with—that maybe there's actually something that we can learn from it. Yeah, absolutely. When we know the roots of the technology that we have today and when we can see the progression of how things change from one iteration to the next, it gives us a bit of a better understanding of how the technology that we use today, how the more modern technology works. And can give you a better working knowledge of how to handle it and how to work with it. The other way it could be beneficial is that that legacy technology, it's still out there and if you know how to work with it, you can really start building a career out of making sure that people are able to use that technology when that hit by the bus scenario happens, right? Oh God, I hope that doesn't happen. I hope not. But Johan has a point. Sometimes it does make sense to familiarize yourself with these technologies and don't run away from them because they're still in production, they're still running huge businesses and infrastructures. So we should not be afraid of them and say, "Oh, that's old and I don't really want to learn about it." We should definitely try to take a different approach because things don't go away quickly. We should always take this opportunity to look around at what was happening at the time, understand when this application or whatever is running in this black box. (18:43): What else was happening inside of technology? What did tech look like? So you can make some similarities. Look at who the players were back then, who's still around today, and what are they doing? It really does help you understand the where we came from and the where we are now, and bridge that gap in between. I think if we thought of it more as a history lesson and an opportunity to enrich ourselves, we'll be doing ourselves a big service because it all came from somewhere and technology is so interwoven. Why not take the opportunity to learn a little bit about it? Mm-hmm. Yeah, it's like new technologies don't come- Based on something, They don't come out of thin air. Exactly. Based on something— They evolve from things that came before it. And you can probably hear echoes or... What's the metaphor I want to use? Or if you look into its DNA, you can see previous generations past. There you go. That's something that Jim literally does with his classes is he'll start with really old computers and have the actual hardware in front of the class and say, "Okay, here's the CPU, here's what it does. Here's the memory, here are the expansion slots," and then he'll move from that to the next generation of computers, which is a little bit more complicated, but he can start showing, here are the parts that they have in common. Here are the additions. And he does that iteration by iteration up until you have an iPhone and he shows them a picture of an iPhone and they can say, "Oh, okay, there's the CPU, there's the memory. Here are all the different components that we have in common between the iPhone and these oldest computers." That's super smart. That is fascinating. Yeah, it's really wonderful. I wouldn't mind taking class. I would love to take that class. So we've been talking about Jim's classes, but that's only part of what he does. He's also a consultant and he recently had a case to work on that unfortunately had to deal with that broken chain of knowledge. As a consultant, I recently helped out a client who was running FreeDOS on some industrial equipment. Basically all this had been set up by this person's dad who had passed away, and a key piece of the equipment was running on FreeDOS. And he came in to take over the business and he didn't know how to run this because I mean, DOS? It's 2023. Why would you run DOS? DOS was one of the first things that I used. I think I was like, I don't know, five years old. And do you remember how to use it? I don't think I do. But there's some parallels. If you get on a command line in DOS, you will be able to figure things out in the same way that you can figure things out in the terminal today. So it had to come from somewhere. There are parallels. I'm sure you could figure your way around a DOS command, Brent, given the opportunity. So this situation is something that Jim runs into all the time, and thankfully he was able to help this person quite a lot. So we went from at the beginning of that, not really knowing anything about his specific system and using that knowledge to like, "Okay, now we can actually figure out what programs are being run to run this industrial equipment." And he was then able to start using the industrial equipment again to make parts. It was a milling machine. So Jim is making a living with this kind of work, right? And the farther along we go, the more technology gets piled up in this category of legacy as the industry moves on to newer software and newer hardware, but that hardware is still around and a lot of the times it's built to last. And there isn't always an option to upgrade the software for that hardware, but there are ways to find the information you need if hiring a consultant isn't feasible. I would say fortunately today, a lot of stuff has been scanned and put on the internet somewhere. When I was going through college, if I were going to try and find a user manual for an Apple II computer or something, which would've been equally distant from some of the tech today, I would've been hard pressed to find that book. There's a lot of stuff you can find online these days. I continually am surprised by how you can just go on and find some old manuals for really obscure technology. That's not always possible, but sometimes you can find things that would surprise you. Jim also mentioned that there are a lot of communities online who talk about these technologies, people who used to work with them and just reminiscing or hobbyists who have found this technology, this hardware, and they want to make it work again. It might take a little digging to find them, but if you're in need, you may strike gold. For example, one question was, I have data that's in an arc file, an old archive file before zip, I have data in an arc file. How do I get it out? And today, in 2023, if you have never encountered an arc file before, you don't know what that is and you may not even know where to start. And you ask on a group like that and it's like, okay, well, we're not talking about that all the time, but we lived it. And so we could tell you. Okay, so what this is, is a special archive file and the program that can read that. There were two programs that read that. And so here's the file, here's the program you probably want to go and find. The first thing I would do if I see a file with an extension, I had no idea it was, Google it. Like, what is this? Is this a virus? What is this? What kind of file is this? Is it music? I don't know. But that's how we start trying to figure out exactly what is it, and then from there you continue Googling or find helpful groups like these that could shed some light on what an arc file is. I love that your first reaction when you don't know a file extension is, is this music. I said virus first. She did say virus, yeah. Then I said music. That's one thing to be a little bit careful of, right, is sometimes if you Google something, some of the malware sites out there have become very sophisticated in that they'll take whatever your search query is and just put it in their own answer. And then you download whatever software they have on there to say like, "Oh yeah, read this with this software." And then it'll... Just be careful that you're not downloading something malicious. Insert evil laugh basically is what you're saying. Pretty much. But yeah, so that's why sometimes those communities can be very useful or online forums or something along those lines. And they can tell you which software is safe and actually reputable for reading these types of files that you may encounter. I imagine that they're probably pretty friendly communities who probably enjoy helping people out like this, right? I'd certainly hope so. Exactly. Imagine. So think about what your favorite hobby was when you were in third grade, and if other people shared that hobby and you had a place that you could go to and talk and reminisce and talk about the good times and the bad times about this part in your life. Those are sometimes the best communities to be a part of because you have that thing that binds you. Now, unfortunately, those people aren't going to be around forever, so it might be in our best interest to find the Pauls and the Jessicas out there who can pass on their knowledge and really spend some time with them and learn what you can. I like that idea. So we're talking about legacy technologies in this series and in this episode we've really been talking about how it's both pervasive and persistent. There is no world in which you are not going to interact with legacy technology in some form or fashion. And it's not that we just have to cope with it or deal with it or something that we should run away from. Maybe it's something that we can learn from, and maybe it's something that we should in some ways embrace and maybe even dig into a little bit. Now, Johan, where are we going from here? This is a series. Yep. Where are we going with this? Well, over the next few episodes, we're going to talk about old languages. We're going to talk about hardware specifically. And we're going to talk about old databases and a whole host of other things. I can't wait. Up next, we're going to talk about the foundations of technology that are literally gathering dust, and that's legacy hardware. That's so cool. You know what? I'm going to go in my closet and I'm just going to start digging through this tote I have that has all these legacy cords and peripherals and adapters and whatever. And I'm never going to throw them away, because you never know when you're going to need— You never know when you might need those cables. You never know. So I am so glad we had this opportunity to jump into this new series. After you've given it a listen, tell us what you thought about it. Do you have any legacy hardware or software or anything where you work? Tell us what it is because we want to know. Give us a tweet @RedHat. Make sure you use the hashtag #CompilerPodcast. We would love to hear your stories. What kind of legacy software is running where you work? How do you work with it? Tell us all about it. And that does it for this episode of Compiler. Today's episode was produced by Johan Philippine and Caroline Creaghead. A big, big thank you to our guests, Jessica Cherry and Jim Hall. Victoria Lawton makes sure we recognize the giants whose shoulders we stand on. Our audio engineer is Kristie Chan. 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 a review, share it with someone you know. It really does help us out. Thanks so much for listening. We'll see you next time. All right, 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.

ブログ記事

Red Hat Named a Leader in 2025 Gartner® Magic Quadrant™ for Container Management for the Third Consecutive Year

2025年 8月 11日  |  Sara Buffington

...

Containers

ブログ記事

Red Hat Named a Leader in 2025 Gartner® Magic Quadrant™ for Cloud-Native Application Platforms for the Second Consecutive Year

2025年 8月 7日  |  Alexa Overbay

...

Cloud services

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.