Hey everyone, I'm Mugum2 Developer. Team, my name is Jonathan Cutrell and in today's episode I'm going to be talking about the truth about old code. It's easy to look down on code that is old. When I say old, I mean if you look at a GitHub repository and if you're like me, you see last updated three years ago, it's easy to think that that code is somehow less than or somehow not as stable as code that has been updated more recently. And perhaps the intuition for this kind of thinking is not off. We want to make sure that the code the code base is actively being developed. For example, if new things are coming out in a language or if deprecations are occurring around a particular API, we want for that code to be updated. And so when we see code that's three years old, maybe intuitively we're thinking that that code has not been updated to reflect the changes in the API or that code has not been updated to take advantage of new features in the language. But I want to flip the script a little bit and help you think about code a little bit differently, particularly old code a little bit differently. Well of course an inactive project is going to have issues that an active project may not necessarily have. There's nothing particularly wrong with code that is aged code that has been around for a while. So for example, let's say there's a Ruby project that you find and you want to use in your project, maybe a gem like device or even a gem like can can. These are really commonly used gems for Ruby on Rails projects. If you look at a piece of code in those gems that hasn't been updated in maybe two or three years, it's easy to think once again that that code is somehow underperforming that somehow it's been left behind and it's not going to do well. But the real truth is that old code has quite a few advantages over new code. Perhaps the most important advantage that old code has over new code is that it has been used for far longer. So more scenarios of that code being tested in real life, more scenarios have occurred. And most of the time bugs that occur in your code are not because of language features or API mismatch. Most of the time those bugs are going to be actually because of an edge case that you didn't think about or improper test coverage. And a lot of those things have been uncovered for that older code. That old code has been around long enough to be tested in real life, to be actually run through its paces. This also applies to your own code, not just to projects that you want to use as a part of your project, like an open source project that we were mentioning before, but it also applies to your code. So in other words, if you have a project that is five or six years old and you've been working on that project and you've been adding features over time, well, certainly you may come to a point where you feel like this project is old and a lot of pieces of it are out of date. And we might as well just throw it away and start all over. However, most of the time in most cases, it is much better to refactor the code that you already have than it is to start from scratch. Let me say that again. In most cases, because your old code has the knowledge of time, the knowledge of testing over a period of time, and perhaps has a significant number of small changes, small fixes as a result of that time tested period, as a result of that scenario, it is more likely that you will be successful if you refactor your existing code base, then if you were to rewrite your code entirely, rewrite the project entirely. Now the success will depend on a few factors. Number one is going to be your testing methods. You need to have a robust testing solution for a refactor to work properly. Because the reality is you've got a code base that may have a bunch of kind of Frankenstein features, right? You've added features over time or you've added bug fixes, exceptions to the rules over time, and what you want to do is refactor those Frankenstein pieces into a nicer code base. That's the typical scenario for a time-tested five or six-year-old project that somebody's trying to refactor. But the only way that you can successfully refactor project like that is if you first have a way of knowing that your new code is not breaking your old code, and that requires some kind of rigorous testing, regardless of whether it's automated or manual. But as long as you have a way of verifying that your new code isn't breaking your old code, as long as you have some sort of verification process, then typically you're going to want to choose refactoring over rebuilding. Even though it feels good to rebuild, even though it seems intuitively that a new build of fresh code base is going to perform better than the old code base fixed, you're actually going to run into all of the same problems that you ran into previously. But now you have to rewrite those same bug fixes. You have to go through the same knowledge-gathering processes that you went through over the last five or six years in that previous project. You have to go through all of that again. Now, of course, there are some benefits to rewriting something entirely from scratch. For example, you can build the entire code base test-driven first rather than trying to retrofit tests. You can take advantage of the latest software packages. But the reality is, when you refactor projects, you have the opportunity to refactor into those new software packages. What this comes down to is shifting your understanding from thinking about physical objects being upgraded. For example, a car, like a 1960s car, we think about software that way. What we need to do is shift our thinking away from the physical upgrade and to the virtual upgrade. And here's the big difference. Refactoring does not mean that you're sticking with an old system. Refactoring doesn't mean that you're holding on to all of the Frankenstein components. Your existing code base should be treated as knowledge. Your existing code base should be treated as knowledge. And you don't want to throw away that knowledge. You don't want to throw away all of that learning that you spent time gaining. Your refactor is just as effective, if not more effective, than replacing the entire system altogether. So the truth about old code is that sometimes old code is better than new code. Thank you so much for listening to today's episode of Developer Tea. I hope you enjoyed it. I hope that it will help you make better decisions about when you should write something new versus refactoring something that already exists. Most of the time, the kind of TLDR version of today's episode, most of the time refactoring is going to be your friend. So go forth, refactor your code. Thank you so much for listening to today's episode. If you're enjoying Developer Tea, make sure you subscribe in whatever podcasting app you use. It takes just a few seconds. If you open up your phone or if you're listening on a computer, open up your computer to whatever app you're using to listen to this episode, go ahead and press subscribe. That will ensure that you don't miss out on future episodes. Thank you so much for listening to Developer Tea. Until next time, enjoy your tea.