Listen or read below.
Carlee – Hi, everybody. This is Carlee, and you’re listening to the Business Advantages With Custom Software podcast, the show that helps businesses achieve more with software. I’m here with the President of Tornado Technologies, Mark Roshon, and the General Manager, Tom Loya. Today, we will be discussing what to do if you’re told your software needs to be completely rebuilt. Mark, how would you go about helping a client with this problem?
Mark – Well, thanks, Carlee. This topic is really about businesses that have old software or legacy systems and must deal with a very common question, should we continue to maintain this software or should we start over and rebuild a new version using modern technology, or at least give it a major upgrade? And certainly, things like urgency and business needs factor into this. Hey, if it ain’t broke, don’t fix it. We’ve all heard that. And it’s quite true for software as well. We have a manufacturing client that is still using a production scheduling app that we developed in 1998. It does the job and their process really hasn’t changed. There’s no reason to rebuild it. Now, since it uses old technology, I believe it was a Visual Basic 6 app using Microsoft Access as a database, it must run on Windows XP, which is difficult to find these days. And several years ago, they set up a virtual image running Windows XP so they could utilize new operating systems. This allows them to have a new computer running, let’s say Windows 11, for their typical business applications. But when they launch the scheduling app, it runs in a special window that simulates being in Windows XP.
Mark – However, many times this rebuild question is more urgently forced upon a business with an event such as an unplanned disruption. For example, the original programmer or company is no longer available, or perhaps a critical technology or service is no longer supported, maybe the workflow for the business has changed and the software needs to accommodate it. Now you have to take action. So you reach out, you contact a software development company for help in making what you hope are just a few minor tweaks, and then you hear the dreaded response. “Your app is too old. The only solution is to either rebuild the application or purchase an off-the-shelf alternative.” What? That is not what you want to hear. And this may indeed be a correct and honest assessment. But sadly, there are many unscrupulous developers that simply do not want to deal with old applications, especially if that application was written originally by someone else, or they know that a rebuild will be a larger project for them, and they are counting on the fact that you may not understand the internals of the software very well. Now, certainly, many developers may be on the up and up, but they simply don’t understand older technology and therefore can’t fully assess the situation.
Mark – You could literally ask four different developers and get four different recommendations. So what should you do? Unfortunately, we don’t have a simple litmus test for this rebuild question. However, we can give you some areas to consider when faced with this solution. Tom, I know you’ve dealt with both sides of this question. Could you share some of your insights into those decisions?
Tom – Sure. Sometimes a rewrite does make sense, and sometimes it doesn’t make sense. I think you established that already. I’ll give you a time that somebody asked us to specifically rewrite something, even though maybe they didn’t have to. This was the CTO of a company that was running… They had their own software that was all homegrown. Some of the software is using new technology, but they had this one program that was written in progress in the 80s. So this was over 40 years old and it’s really old technology. He said, “Tom, this is the one project that we have that I lose sleep overnight. I want to get this rewritten.” And this was back about 5 to 10 years ago that he said this. And so we did. It was something that it made sense to do a rewrite because it was such an old technology. It was 40 years old, and he wanted to do a rewrite because he knew that if there was some disaster, it would have been incredibly hard to recover from that disaster. Well, guess what happened? They got hit with a ransomware attack, and this was just a couple of years after we completed the rewrite.
Tom – Our rewrite actually integrated their old 40-year-old system into their existing software, which is running on new technology. So it was all built under the same umbrella, the same technology. It was all part of all their backups that they had and everything. And this old progress system wasn’t even needed anymore. It was really pretty easy to recover from this ransomware attack. I would say that at the end, even though it was a lot of work to get the rewrite done in place, it didn’t cripple their business. And I would say that because they did this, it saved their business from a collapse, from a total destruction from the ransomware. Either that or they could have paid an incredibly large amount to these ransomware companies. And that’s a topic for another day, not for today. But it’s not always the best decision to upgrade old software. Mark, you brought up that software that you wrote in 1998, but they have a plan in place. They have the virtual machine, they have these things in place so that if there is some disaster, they could work with it and triple them. But sometimes the software is old.
Tom – There’s projects that we wrote 20 years ago that was written in .Net 2.0 or .Net 3.5, and it’s old software. That’s an old technology, but you could still upgrade that software to be with the latest .Net, and it’s not worthy of a rewrite. You get a lot better security. You get all sorts of benefits of using the latest technology. Plus, you know it’s going to be supported for a lot longer. And really the migration from this old .Net technology to the new .Net technology is pretty easy. Sometimes you have to fix some incompatibilities. That’s part of upgrading. That’s part of software maintenance and upgrading. That’s a good thing because your software is getting better, but there’s no reason for rewrite. An interesting thought there, Mark, that VB6 app that you wrote back in 1998, if they wanted to do major changes to that, is that worthy of a rewrite? That’s a good question. I don’t know if it necessarily is because we can still make changes to that software. It’s relatively easy. VB6 is still available right now. It’s not necessarily fully supported anymore, but you can still build VB6 applications. You could still make changes to them. It’s not hard to do. There’s still a lot of VB programmers that could do this. Now, maybe those VB programmers are now VB .Net programmers, but the languages are real similar.
Mark – That’s a good point. Obviously, if they just wanted an extra report or they needed an extra field or two to help decide the order of their production, I would agree. There’s no reason you wouldn’t just modify that program, even though it’s so old, because it’s just a few hours to make some of these changes. Certainly, if they was looking for an entirely different workflow, now at that point, instead of trying to… Because sometimes if the design flows different, it’d be like trying to pound a round peg into a square hole. That would be a good example where you say, Oh, well, let’s just take this opportunity. As long as we’re going to make so many changes, we might as well incorporate a new technology.
Tom – Yeah. And you can upgrade a VB6 app to be into VB.Net. It’s not the cleanest process, but it can be done. It’s not doing a full rewrite, but it’s like both of them put together. It’s not a rewrite, but it’s not as simple as just taking .Net2, to .Net 4.8 or a more modern .Net. It’s in the middle because VB6 operates differently than VB.Net. It can do a lot of the programming for you, but there’s going to be a little bit more, probably a lot of it more fixing minor things to get it to work. But it’s not going to be a full rewrite. It might be like a one quarter amount of effort than it would be to just rewrite the whole thing. Maybe half, I don’t know, but it’s not going to be nearly as much to do a full rewrite.
Mark – Another thing to consider would be just the people that are needed for that technology or that have skills in those areas, are they going to be easy to find or hard to find because that’s going to affect the development cost or the maintenance cost
Tom – Mark, I’ll stop you right there. That example I gave with the progress software, it was 40 years old. The company had a really hard time finding old progress developers that could make changes. So if they wanted to do just a tiny, minor change to their 40 year old progress system, it was always very costly because they had to use specialized programmers. People who programmed that stuff 40 years ago, they’re going to be top level software developers. Then they know they have a niche skill and it costs this company quite a bit of money just to hire these contractors for just a little bit of work. When we rewrote it to be in net, I hate to say it because I’m a net programmer, but there are a lot of us, it’s not hard to find a net programmer to make changes. So now they can make changes to their software with a whole lot of people. And it’s a lot more reasonably priced to make those changes than it is to find a specialist who can update old progress code.
Mark – Great point, Tom. As far as creating new apps, I’m sure you’re like many developers, you really enjoy creating that new application, the new design. But the truth is that over 60% of our work involves maintaining existing systems. And many of these systems, we’ve had no contact or access to the original developer. How do you view maintenance or support on legacy systems?
Tom – Well, I will confirm right off the bat that I do like working on my own projects from the get go. Normally you can develop stuff that you write from scratch really fast in the beginning because you’re just building things and you don’t have to deal with old problems. But sometimes old problems are also fun to work with. It could be very gratifying, and I’ll give you a great example. One of these really gratifying things is when you can help a business become a lot more efficient or make them do their job better or faster or become more productive with just small changes. Sometimes the small changes can have such a big impact. This company called me and they said, “Tom, we have this grid on the software we’re using that’s always scrolling to the bottom whenever you make a change.” So they go make a change and it would scroll to the bottom of this grid. This grid had about 100 or 200 people listed in it, and it kept track of all sorts of data for these 100 people. Normally, she said, we just live with it because we’re going to make a single change or something real small.
Tom – They could scroll to the bottom. It did that automatically and then they could just go up to where the person is they make the change. But there was a change that had to be done to every single person in this grid. So you could just imagine how long it would take just to make let’s say they made ten changes. It would take forever for them to make these changes because they have to scroll all down. Every single time they made a change, it went to the bottom. So I found a fix for this. And if the software was being updated regularly, kind of like you were given with the iPhone example, if the software was being upgraded to use the latest software or the latest technology, it was really a third party grid that was being used that had a bug that developed over time because software systems change. They did have a workaround for this specific version, and I put that workaround in and I released it and she said, wow, this software is such a delight to use right now. And who has fun using a grid going in the software and just updating grid is it really fun to update, essentially that’s a spreadsheet is it really delightful.
Tom – But it was so painful for her before to make such small, simple changes that all of a sudden it was so easy to make changes. It was very gratifying for her, and it was very gratifying for me that the simple change really made her life a lot easier and it made her a lot faster at what she had to do.
Carlee – Thanks, Tom. Mark, any final thoughts?
Mark – Sure, Carlee, I’ll just end with this. Try to discuss the lifecycle of your software before you’re forced to make a quick decision and treat it more like an important medical decision where a second or a third opinion would be very helpful. I’d be happy to have this discussion with a business and help you create a roadmap. Just give me a call and we’ll set something up. Thanks. Back to you, Carlee.
Carlee – Thanks, Mark. All right, well, thank you for listening to Business Advantages with Custom Software podcast with your hosts, Mark Roshon and Tom Loya. We hope you enjoyed our conversation about what to do if you’re told your software needs to be completely rebuilt. As always, you can head over to learn more about Tornado Technologies, located in Cleveland, Ohio on our website, tornadosoft.com. That’s all for this episode. See you next time.