Leaving A Legacy

In this podcast, senior software developer Christopher Keefer shares his insights on a "Legacy" codebase and the different approaches you can take toward a legacy transition. We even talk a bit about the impact of legacy software on the healthcare industry and what it means to have a properly air-gapped computer.  

Transcript

SPEAKER_00: 0:01

Hi, welcome to the Art& Logic Minimum Viable Podcast. Today I'll be speaking with Christopher Kiefer, one of our developers at Art& Logic, and we'll be discussing the transition from a legacy solution. Christopher, can you introduce yourself and tell us a little bit about what you do for Art& Logic?

SPEAKER_01: 0:25

Oh, why, hello there. I'm Christopher Kiefer. I'm a senior software engineer here at Art& Logic. Been working with the team for about a decade now. What do we do? Well, the right question is probably, what do we not do? And there's not too many things that fall into that categorization. So the kinds of software that I've had the opportunity to work on at Art& Logic are go across a vast range, but they include things like financial software, scheduling software, graphing software, reporting software, interactive graphical software. Let's see here. We've done design work. That is applications that are designed to allow for designs. We've also done work that's or I personally have worked on projects that were about fit and finish on various manufactured items. I've also done work on hiring processed software. So a vast conglomerate of very disparate items.

SPEAKER_00: 1:40

And in your work on those kinds of projects, have you come across instances where it was an update from a legacy code base to something that needed to be more current or that needed to tackle different types of problems that weren't anticipated back when the first software was created?

SPEAKER_01: 1:55

Oh, yes, definitely. I don't think it's... The majority, but a good 40%, let's say, of the projects are people coming to us not with a brand new idea that they've never tested, but with an old idea, an idea that they've been working with, maybe that their business was even founded on originally. And they've been churning on it and churning on it. And it's finally, it's broken. It's not good enough anymore. Or it's not doing the things that they needed to do now. Now that their business has grown larger or more complex and looking to us to turn whatever current solution they have into something that's more powerful, more flexible, meets their current needs.

SPEAKER_00: 2:33

And when a client comes to us with that kind of a change in mind, do they often want us to just build off of what they already have and maybe try to make it stronger? Or is it... often a matter of trying to explain to the client that look, what you had was great, but if you really wanted to achieve what you're trying to achieve now, you need to do something different? I

SPEAKER_01: 2:54

would say yes. Oftentimes, what happens is the client will come to us and say, so I have this current solution. I know it's not good enough. What should we do about it? Sometimes they have a strong opinion about what we should do about it. They think if you could just add these couple of things, it should be simple and easy. You can do that, right? And then when you actually get into the thick of it, you realize, well, when they say a couple of things, they actually mean a couple dozen things that are all interrelated in some way and all very difficult to do with. whatever their current solution is. Or they'll come to us and say, I know that this what I've got right now is just it's no good. It's, I've got 15 people working on this manual process, or, you know, I've got 20 people in the back office all trying to keep this thing running. And it's just a huge time sink, and it's time to throw it away. But I don't know how to do that. how to be rid of it and onto something that'll actually fit my needs and not suck all of my employees' time down. How can we get there?

SPEAKER_00: 4:01

So it

SPEAKER_01: 4:01

really runs the range.

SPEAKER_00: 4:04

And are there also sometimes instances where the older solution is no longer accessible or requires some kind of deprecated technology that you can't use anymore in order to see what they were doing? Or how do you handle that kind of situation?

SPEAKER_01: 4:18

Well... We definitely have that kind of thing come up often. There's certainly a class of client in this particular realm of transitioning from a legacy solution where they're only committing to coming up with something new because the old thing is is kaput or is just about to be kaput. They've been running a 40-year-old console-based program on a Unix machine. It only works on Now, a Park Unix machine that they purchased secondhand 50 years ago, and they know it's about to give up the ghost, so it's time to move on. Or they've got even a relatively recent piece of technology built on something like Flash or Silverlight that has been deprecated for a long time and is about to go into end of life finally. And so they're finally committing to, okay, I guess we have to move on.

SPEAKER_00: 5:21

So are there also times when maybe if you're talking about a program or a console-based program that was written 40 years ago and had been used by employees during that time frame, that some of those employees that had some access to the information, to how it was used, to how it was taken advantage of by their own customers, do you need access to those people or can you work around that when necessary?

SPEAKER_01: 5:47

You can work around it, but the result is going to be an increase in the time and cost of the project. Really, access to the existing solution is only step one. The next step is to have access to the people who are interested in replacing the solution, to get their idea of what the new solution needs to do. And then the third and I feel honestly most critical element is having access to the people who are using it day to day, not just to figure out how is the solution actually being used, not necessarily the same thing as how the management think it's being used and also identifying. So what are the major pain points with the current solution so that you don't end up just replicating those pain points, but actually create a solution that's superior to the old one in every way.

SPEAKER_00: 6:42

And so once you have an agreement or an understanding of what kind of solution you want to implement, what kinds of approaches are there to making that legacy transition?

SPEAKER_01: 6:53

The approaches, I would say, are roughly four. The first one is what I would call immediate mothballing, where you they have the solution, they know it's no good, or it's not meeting their needs anymore, or maybe they've lost access to whatever system it used to run on. It was supplied by some third party and the license has run out or it was on some ancient machine. It was running on a Windows 95 box and the box died and they can't get anybody to figure out how to put all the pieces back together. So it's already mothballed. The solution is gone. All you have is whatever documentation they have, whatever source code they might be able to supply and the people who used to use it. This can be one of the easiest approaches for development because it means you're not trying to support an existing legacy application in any way, but it can also lead to a lot of urgency in the development, which can sometimes be problematic. You don't want to rush the creation of a solution in a couple of months that you've been using for 20 years. The time that it took to evolve that solution and to get your business used to it will be part of the experience of building the new one. The second approach I would call parallel, which is you have the old solution. It's still ticking along, but you know that it needs an improvement. It needs changes and improvements. you could try and build on the old solution, but you know its days are numbered one way or the other, or it would just be costly, more costly to try and build on top of than to replace. And that's something that we often help people work out at the beginning of this kind of project is to take a look at their existing code base or their existing solution and say, is it reasonable to try and build on this versus trying to build something new that would do the same thing plus. Oftentimes, we'll take a look at an ancient code base and say, you know, you could build on top of this if you really want to, but it's kind of like building on the sandy beach. You know that there's going to be some problems in the long term that you could eliminate entirely by building somewhere else, building somewhere more solid. The Parallel Plus is the third one, what I would consider the third approach, in that there is a legacy application and it needs new features right now. But you also recognize that it's not good for the long term to try and keep supporting it. There's something about it that is going to hold your business back. And it's time for it to be replaced permanently. But at the same time, you really need something new right now. And so you can have our development team step in there and improve the existing application, add new functionality to it, do whatever is needed there just to shore it up for the short term, while at the same time gearing up to create a new solution that'll meet your real needs, long-term needs as well as short-term ones, and be more maintainable in the future. And then finally, there's the most costly and difficult approach, but one that sometimes needs to be taken for whatever reason, and that's intersecting, where you have a legacy application and a new solution. The legacy application is going to continue, at least for some time. The new solution is under development, and they both have to rely on some shared elements. If you have a database in the backend, for instance, that contains... years and years of client records and rather than transition those client records into a new database solution you're determined you're going to use the existing one or for whatever reason your legacy solution and the new solution need to run parallel for a while and they need to work on the same data this is where you end up with an intersecting uh this intersecting scenario where the new solution and the old solution not only have to work alongside each other, but have to work together in some way.

SPEAKER_00: 11:24

Of these four different approaches, which do you think is most common for the Art& Logic client?

SPEAKER_01: 11:31

I would say that the parallel approach is the most common, where they have come to us in time to begin work on new development without putting their business at risk. They're aware that a problem is coming up. They can see it coming around the corner. They're going to lose access to some system. They're going to, like eventually the box they're running this ancient software on is going to die or whatever. And so they've come to us with enough time to say, okay, we need a new solution. We'd like it to work like the old one, plus these new and improved features. And can you get started on that? And we say, sure. And in the meantime, they continue running their old solution. That might be a bunch of Excel spreadsheets. It might be a handwritten process. It might be an old piece of software, whatever it is. And then we slowly introduce the new solution. We get their users, the employees who are using it at the business or their own clients to start using it slowly as a beta test set of users. And It slowly but surely replaces the legacy application or the legacy solution without any hiccups, without any bumps in the road or any discontinuity between the old and the new.

SPEAKER_00: 12:48

So the idea of discontinuity between the old and the new actually kind of brought a question to mind for me that I would really like to ask you based on your expertise. Given that we're living in this very disruptive time where a pandemic has kind of shaken up a lot of what we rely on, not just for our work, but also for the communication of our work. Have you seen any instances in the public space of real problems of existing legacy software where it's actually impacting something about how we're getting through this pandemic? Oh, goodness.

SPEAKER_01: 13:25

That is a question that is needed to be asked, but it's a little loaded because the place that I have mostly seen it in the last couple of months is in healthcare.

UNKNOWN: 13:36

Mm-hmm.

SPEAKER_01: 13:36

I was actually at a doctor's office just a few days ago, and I saw them working away at the computer as they were entering in some patient records. And I recognized the little Start logo in the lower left corner, and I said, you're not still running Windows 98, are you? And the woman at the computer shamefacedly looked up at me. You know, it's hard to tell above the mask, but she definitely didn't look pleased about the situation. Said, yes, yes, we are. And went back to work. I've seen similar situations. Actually, I was at my dentist just before this pandemic hit. And they were still using Windows XP, which, as we know, has been delegated to the dustbin of history not too long ago. And I was asking them, so how come you're still on Windows XP here? And they said, well, this piece of software that we have to work with only runs on XP. It has to talk. And she pointed to the X-ray machine in the room. It has to talk to this X-ray machine. And it also does our scheduling. and it does a bunch of other things, and it only runs on Windows XP. We tried upgrading to Windows 7, and it didn't work, so we had to downgrade again. And that's exactly the sort of thing that I would be thinking of as a legacy system that desperately needs to be updated and brought into the present. Windows 7 itself is nearing, if not already, at its end of life, and here they are still on Windows XP. held hostage there by this legacy software.

SPEAKER_00: 15:32

Yeah, I guess that's what happens is that after companies and medical practices, for example, create their own dependencies on this kind of economy of software and devices and hardware, then it's really hard for them to break away from that because, well, it's familiar and it's also expensive and And I guess the risk of trying to use any new software that can't communicate with any of the hardware that you rely on is just too great. So, yeah, I could see that being very troubling. That's actually a perfect example, I think, and something that I know different companies have been trying to tackle. I remember going to South by Southwest four years ago, and there were at least six or seven different companies there that were claiming to have overcome this very problem. And unfortunately, I think maybe one of those companies was there the following year, and the rest, I don't know if their solutions ever came to any kind of fruition or what happened, but I haven't seen any impact of those changes anywhere. Right. In my own experience, when I go to get any kind of medical service, and if I don't go to the same place, like here in Southern California, you can stick to UCLA or USC. But if you go to different providers, then your records don't follow you. And it makes it very, very, very difficult to get the kind of healthcare that you need. And part of it is, I know, privacy regulations, part of it is that Providers don't want to share the information so easily with one another in order to keep you within their organization. But then, you know, the cost of that, I think, is enormous. And I worry about how we're seeing that play out now at a time when many people could be relying more heavily on consistent, easily accessible information and diagnostic tools that just haven't been presenting themselves quickly enough.

UNKNOWN: 17:24

Yeah.

SPEAKER_01: 17:25

Yes, the human cost is one that we really shouldn't be willing to pay for the sake of keeping compatibility with outdated software or hardware. One thing that we have sometimes done in the past to help work around this sort of problem where they have, say, drivers that were designed for a specific operating system and a specific piece of hardware and it only works there is we can say, well, tell you what, The biggest risk surface that you have is whenever you expose a computer outside of your local network. If it's something that can interact with other computers without any restriction on that, if it's something that can, God forbid, interact with the Internet at large, you're putting yourself first. your business, your customer is at a huge risk. Instead, what we can do is we can have a new piece of software that does some of the things that you need it to do. If you're not willing or able to engage with customers creating new driver software, getting that certified. I understand in healthcare in particular, there's a great many hurdles and a lot of red tape. And that's good because we want to protect people and we only want to offer solutions that are going to work and are going to be safe. But at the same time, there's a huge risk of like you say, incompatibility between systems. Having healthcare providers fax documents to one another does not do anything to preserve privacy and certainly adds a huge amount of overhead and the possibility of lost records, lost data, misinterpreted things as each new medical provider has to type in things from a potentially poor fax copy. Instead of having that because we're being held hostage to some particular driver for a piece of hardware, the software that can be updated could be created separately and a VM, a virtual machine, or a single air-gapped computer with very strict rules on local network access and absolutely no global internet access can be set up. And then you can have the software on the new secure computers talking to that one computer that's in control of the legacy drivers and the legacy hardware, but nothing else. That computer is now, you've reduced your risk surface to a very small point, whereas before it was a neon glowing sign to anybody who had an axe to grind or spare time on their hands.

SPEAKER_00: 20:06

Well, thank you. That was actually really insightful, and it helped me a lot with my understanding of one of the vulnerabilities of healthcare and why an air gap computer can be a solution to that. I've heard that mentioned before, but I hadn't quite heard it explained so well. So thank you for that. I appreciate it.

SPEAKER_01: 20:22

No worries. That's not exactly an air gap, so I'm going to be an engineer, a silly engineer here, and go into the super details. A truly air gap computer should be connected to nothing else. You should have to walk physically from one computer to the other computer, and you shouldn't be able to talk between computers. And if you even allow people to plug anything in, there should be a a keyboard that's hardwired in, it should be a monitor that's hardwired in, all of the USB ports should be filled with epoxy, that's a true air gap computer. But this is the next step up from that while still greatly reducing your risk surface, just to have a machine that only talks to one other machine and it only allows a specific port and it's verifying through a firewall software or something like that, that only certain kinds of messages are coming through and only being processed a certain way. Not a perfect air gap, but much better than having a Windows 98 box talking to the Internet, like I saw at my doctor's office not too long ago. Right.

SPEAKER_00: 21:32

Is there anything else that you wanted to add about... I know we veered away a little bit here, but is there anything else you wanted to ask specifically about legacy transitions or legacy solutions?

SPEAKER_01: 21:41

The only other thing that I would add... based on your question and thinking about healthcare and how it affects people in general, is that sometimes we have had a client come to us for a legacy software transition and when they've gotten their hands on the new piece of software, they have said, you know, I never realized how bad it was. It's particularly with those who are coming to us from a sort of ad hoc setup where they've got Excel sheets with increasingly complex equations and pivot sheets and the official version of it and then the unofficial official version of it and version 3.795 of it. And they all have to do slightly different things and everybody has to keep track of which one does what. And when we provide them with the clean one-stop solution even when it's you know still being built even when it's in an alpha version and it doesn't do everything yet or there's still some bugs they tend to say you know this is so much easier and better and smoother and i had no idea how much better it could be so i guess my point really there is that sometimes when you're in the midst of quicksand you don't realize like you've been in quicksand for so long you've been back paddling trying to reach the edge and the edge just seems to always be just out of reach you don't realize that you don't have to do that

SPEAKER_00: 23:14

thank you And I think we'll end it there. Thank you, Christopher. I appreciate your talking to us about legacy software today and sharing with us your insights. It was really very informative for me. And to any of you out there who are listening, thank you for listening. And if you haven't subscribed, please subscribe wherever you listen to your podcasts. And just for clarity, our Minimum Bible podcast is produced by Adam Singleton. It will be edited by Andrew Sherbrooke. And thanks for listening. Goodbye.