150 How Do I Approach Rewriting an Old Codebase?

How do I rewrite an existing project? If I cannot avoid a rewrite, what things do I need to be careful of? What pitfalls are there when starting over after years of development? These are the questions we will answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:24

How do I approach rewriting an old code base? This is a question that really intrigued me because I've answered it kind of before, and I want to make sure that I address the other side of it, which is how do you when you have no other option? So let's talk about how do you rewrite an old code base when you just have no other choice. That's today's topic for this DevQuestion series. If you have a question, go to suggestions.imtimcorey.com and ask it there. Hopefully you'll see or hear your question answered in a future episode of DevQuesti. Okay, so my number one answer always when someone says, How do I rewrite an application is don't. If you can help it, don't. Because it's much better to try and upgrade an application than it is to rewrite the entire thing. But let's talk about why. Because if you if you say, hey, you know what, I can get rid of all these old problems by just rewriting it. Kinda, but you're also getting rid of all the lessons learned. There are years and years of lessons learned, years and years of code fixes and bug fixes and logic fixes that you may not know about that are under the surface of that application. You may look at the UI and say, okay, I put this much data in, I get this much data out. How hard can it be? But there's usually more to it than just that. So when you rewrite an application, you often lose a lot of the positive history on how your code should really work. And what happens is you start to repeat the same problems you had earlier. So that's why I avoid a total rewrite and encourage instead an upgrade process, if at all possible. However, sometimes you just can't help it. For instance, in this particular case, the person said, Hey, I know the upgrades are the better way of going, but I've got a.NET framework project that uses web forms, and it's not even well written. And it's got problems that I just can't ignore. I have to address. I have to redo how this thing does what it does anyway. And so I need to upgrade it as well. It's probably the best to just rewrite the application. So, you know, what do you do in that case? How do you go about rewriting your application? The first step is start small. Don't try to just redo everything all at once. That's kind of the waterfall technique of we've got this plan for the whole thing, we're gonna build the whole thing and then we're gonna release the whole thing all at once. And that is a hard thing to get right. So start small, do a little piece. If it's a web application, which this one was, it that's a great opportunity to redo one page or one feature in a new site. Being able to say, okay, yes, it's a different URL, or maybe use DNS to kind of redirect and move things around. But you know, we're gonna kind of mix and yeah, it's gonna get a little bumpy, but in the end of the day, we're gonna have the ability to slowly move features over. YouTube did this recently when they upgraded how their back-end system worked for content creators. So I spent a lot of time in the back end of the YouTube's content creation system. So things like moderating comments and tracking my videos and uploading new videos and setting their, you know, from private to you know, uh public or scheduled or all the rest, all that stuff that you do behind the scenes on YouTube. Well, that interface has radically changed in the past few years. But it didn't happen overnight. Instead, we were notified, hey, there's a new YouTube interface. Do you want to try it? And so I tried it and it would have some of what I wanted, but it lost some of the things that I needed. And so I'd bounce back and forth, the new user interface for most of my stuff, but they're still missing these things. And eventually they moved all the things, or not all, but a lot of the things over into the new interface and said, okay, we're done. The old system goes away now, it's just the new system. So you can do that if you start small and slowly migrate things over. Now, that does mean that if at all possible, and this is point number two, try to reuse the same database. Meaning, try not to restructure all your apps so that the data goes in different places and it's just messy. Because then what happens is you've got to have some kind of synchronization system between the two systems for the data. That gets a lot harder to do right. So if you can help it, use the same database so that when your new UI makes a change to the data, it's the same data that the old UI sees, therefore the old UI has those updated pieces of data. So if you can do that, that's great. It may require you to write an interface layer between your new system and the database. And that can be okay, where you say, hey, you know what, this is the new structure, but we're gonna translate it through an interface layer to the old database this way. And when we're done, we can upgrade the database to the new way of doing things and take the translation layer out. That can be possible too, but try and reuse that same database. And that leads right into point number three is try not to change everything. This is hard to do because when you look at all the problems, say I can fix this, I can fix this, I can fix this. You know what? We've got a.NET framework web forms project. We're gonna make it a desktop application with also.NET Maui and mobile interfaces, we're gonna use microservices and we're gonna put it in the cloud. We're gonna, wow, that's a lot of changes. And so when it comes to trying to make sure all those changes work and make sure that it does the same thing the same way, and that gets hard to do. Instead, try to change as little as possible. In this case, you're gonna have to change the UI from web forms to something else. Probably a Blazor product, WebAssembly or server, or the upcoming hybrid way of doing things. But um, whatever you're gonna do, you're gonna have to have a different UI. But try and keep as much of the logic the same way and the same type of system, the same database and the same structure and maybe even the same locations. Because the less you change, the less you have to debug. And it's the more you have the similar, the easier to compare the old system to the new system. If the old system is one page where you enter one set of information and it goes to the database, and the new system is five different pages that use three different microservices that asynchronously put stuff in the database eventually, well, how do you compare apples to apples to make sure that you're doing the same thing in the new system that you did in the old systems, accomplish the same end goal? It's hard. But if you have one page over here and one page over here and they both do a similar thing, maybe different UI, maybe different processes a little bit, but a similar thing, it's a lot easier to make sure that when you do your checks to say, yes, the new system is working the way we expect. So try not to change everything. Now it does mean that if you write things modularly, that once you have the new system fully online, then you can start changing things. You could start redoing things if you've thought ahead and said, hey, I want to architect this in a way that is modular so that we could have a.NET Maui app. So you could break off microservices, so you could rearrange this and put this in Azure and so many other things. But don't do it yet. That's my my recommendation. Number four, review the help tickets and past commits. So look at the past. Look at why things changed. If you were modifying a specific page, look at the Git history and say, hey, how has this page changed and why? Hopefully you've written good commit messages that don't just say, may it change, may it change. Hopefully you said why you made a change, what the bug fix was, linked to an issue, and so many other things. But being able to track through the changes and understand why something changed will help you understand is this the can I change this in some way, the new way? Can I change it in a way that makes more sense now? Or am I going to repeat history and this thing over here, the thing we fixed, was because we did it that way originally and that wasn't right and that caused this problem. So learn from history. People who don't learn from history are bound to repeat it. So learn from your past history of help tickets, past history of commits. Try to figure out why your system evolved over time the way it did. Now, some things are going to be because we got new interfaces, because we got new software ability, because we, you know, we want these new ways of doing the processes and our business changed. And those things, you know, they are what they are. And yeah, your business changes, and that's not really a history you need to necessarily learn from. But when it's because the system broke, because the logic wasn't right for your business, that's what you need to learn from. And then finally, number five, you need to interview users. Find out from the people who actually use the software what their thoughts are, how it works, why it works, what problems there are, and how you might be able to, without making tons of changes, be able to alleviate some of those problems. Maybe the system doesn't work right now. Maybe there's a big bug in here where it they make it work, but it's really broken right now, and you can fix that in your new design. Again, trying to change as little as possible, but you don't want to replicate a broken system. So the key here though is to talk to the real users. Too many times, as a consultant, I've come in and said, okay, I need to interview the users. And who they sit me down with are the managers. That is not the user. The manager is not the person who knows the most. In fact, they often know the least. They can tell you overall what the department does, how it operates, what the goals are, what they do as far as processing. But when it comes to the actual day-to-day, how things work, how the system works, how the system operates or doesn't operate, the people who actually put data into the system, typically the lowest people on a totem pole, they're the people that are most likely the people that are going to know the most about the system and how it really should work and does work. So talk to those people, get to understand the system really well. Try and get as much institutional knowledge in your head before you even start this process. And then make sure you keep going back to that to make sure that you are following through and making sure you create a system that really does replicate as much as possible of what the system should do while at the same time avoiding all the pitfalls that is currently doing that you don't want to do in the new system. Okay? So again, if you can avoid it, avoid it. Try and just upgrade and then change over time. But if you really have to redo, start small, reuse the same database, try not to change everything, review their old the past, and then also interview the current users to figure out how the system works now. All right, that's my recommendation for up or replacing an old system with a new system. Thanks for the question. Thanks for listening, and as always, I am Tim Corey.

SPEAKER_01 12:37

Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamTimcorey.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.