Vox

Leitura de 11 min

The Truth About Old Code

Summary

In this episode of Developer Tea, host Jonathan Cottrell addresses the common bias developers have against old code. He acknowledges the intuition that recently updated code might be more aligned with current APIs and language features, but argues this perspective is often flawed.

Cottrell explains that old code has significant advantages, primarily because it has been tested in real-world scenarios over a longer period. This extended use uncovers edge cases and bugs that might not be apparent in new, untested code. He uses examples like the Ruby gems Devise and CanCan to illustrate that stability often comes from maturity, not just recent activity.

The discussion then shifts to applying this logic to a developer’s own projects. Cottrell strongly advocates for refactoring existing codebases over complete rewrites. He emphasizes that an old codebase contains valuable, hard-earned knowledge about edge cases and fixes. Rewriting from scratch means discarding this knowledge and potentially re-introducing old problems.

For a refactor to be successful, Cottrell stresses the necessity of a robust testing strategy—whether automated or manual—to ensure new changes don’t break existing functionality. He concludes by reframing the old code not as a physical object to be replaced, but as a repository of knowledge to be refined and improved upon, making refactoring a powerful and often superior approach to rebuilding.

Recommendations

Tools

  • Devise — Mentioned as an example of a commonly used Ruby gem for Rails projects, used to illustrate that even code that hasn’t been updated in years can be stable and reliable.
  • CanCan — Referenced alongside Devise as another common Ruby on Rails gem, serving as an example of mature, time-tested code that developers might unfairly judge based on its age.

Topic Timeline

  • 00:00:00 — Introduction and the bias against old code — Jonathan Cottrell introduces the episode’s topic: the common tendency to look down on code that hasn’t been updated recently. He explains the intuition behind this bias, such as concerns about outdated APIs or missing new language features, but sets up the premise that this view needs to be reconsidered.
  • 00:01:36 — Advantages of old code: real-world testing — Cottrell argues that old code has a key advantage: it has been used longer and tested in more real-life scenarios. Most bugs arise from unconsidered edge cases or lack of test coverage, issues that time-tested code has likely already encountered and resolved. This principle applies both to open-source dependencies and a developer’s own projects.
  • 00:03:00 — Refactoring vs. rewriting your own code — The host makes a strong case for refactoring an old project over rewriting it from scratch. He states that the old code contains the ‘knowledge of time’—lessons learned from years of fixes and adjustments. Starting over means you’ll likely have to rediscover and re-solve the same problems, making refactoring the more efficient and reliable path to improvement.
  • 00:04:08 — The critical role of testing for successful refactoring — Cottrell details the prerequisites for a successful refactor. The most important factor is having a robust testing method to verify that new changes don’t break existing functionality. This safety net is essential when untangling a ‘Frankenstein’ codebase built over years, allowing developers to confidently improve the structure without losing stability.
  • 00:06:13 — Shifting mindset: code as knowledge, not a physical object — The episode concludes by urging a shift in perspective. Developers should stop thinking of software like a physical object (e.g., an old car) that needs replacement. Instead, they should view an existing codebase as accumulated knowledge. Refactoring is not about clinging to old parts, but about intelligently evolving and preserving that valuable knowledge, which is often more effective than a total rebuild.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2016-09-12T09:00:00Z
  • Duration: 00:08:05

References

Podcast Info

Transcript

[00:00:00] Hey everyone and welcome to Developer Tea, my name is Jonathan Cottrell and in today’s

[00:00:07] episode I’m going to be talking about the truth about old code.

[00:00:12] It’s easy to look down on code that is old, and when I say old I mean if you look at a

[00:00:20] GitHub repository and if you’re like me, you see last updated three years ago, it’s easy

[00:00:27] to think that that code is somehow less than or somehow not as stable as code that has

[00:00:34] been updated more recently.

[00:00:38] And perhaps the intuition for this kind of thinking is not off, we want to make sure

[00:00:43] that the code base is actively being developed, for example if new things are coming out in

[00:00:49] a language or if deprecations are occurring around a particular API, we want for that

[00:00:55] code to be updated.

[00:00:57] And so when we see code that’s three years old, maybe intuitively we’re thinking that

[00:01:01] that code has not been updated to reflect the changes in the API, or that code has not

[00:01:07] been updated to take advantage of new features in the language.

[00:01:11] But I want to flip the script a little bit and help you think about code a little bit

[00:01:15] differently, particularly old code a little bit differently.

[00:01:18] While of course an inactive project is going to have issues that an active project may

[00:01:23] not necessarily have, there’s nothing particularly wrong with that.

[00:01:27] There’s nothing particularly wrong with code that is aged, code that has been around for

[00:01:31] a while.

[00:01:31] So for example, let’s say there’s a Ruby project that you find and you want to use in your

[00:01:36] project.

[00:01:37] Maybe a gem like Devise or even a gem like CanCan, these are really commonly used gems

[00:01:43] for Ruby on Rails projects.

[00:01:46] If you look at a piece of code in those gems that hasn’t been updated in maybe two or three

[00:01:51] years, it’s easy to think, once again, that that code is somehow underperforming, that

[00:01:56] somehow it’s not as stable as it used to be.

[00:01:57] And so if you look at a piece of code that hasn’t been updated in maybe two or three

[00:01:57] years, it’s easy to think, once again, that that code is somehow underperforming, that

[00:01:57] somehow it’s been left behind and it’s not going to do well.

[00:02:00] But the real truth is that old code has quite a few advantages over new code.

[00:02:06] Perhaps the most important advantage that old code has over new code is that it has

[00:02:11] been used for far longer.

[00:02:14] So more scenarios of that code being tested in real life, more scenarios have occurred.

[00:02:20] And most of the time, bugs that occur in your code are not because of language features,

[00:02:26] or API mismatch.

[00:02:28] Most of the time, those bugs are going to be actually because of an edge case that you

[00:02:33] didn’t think about, or improper test coverage.

[00:02:36] And a lot of those things have been uncovered for that older code.

[00:02:41] That old code has been around long enough to be tested in real life, to be actually

[00:02:46] run through its paces.

[00:02:49] This also applies to your own code, not just to projects that you want to use as a part

[00:02:55] of your project.

[00:02:56] Like an open source project.

[00:02:56] That we were mentioning before, but it also applies to your code.

[00:03:00] So in other words, if you have a project that is five or six years old, and you’ve been

[00:03:07] working on that project and you’ve been adding features over time, well, certainly you may

[00:03:12] come to a point where you feel like this project is old and a lot of pieces of it are out of

[00:03:17] date and we might as well just throw it away and start all over.

[00:03:20] However, most of the time, in most cases, it is much better.

[00:03:26] To refactor the code that you already have than it is to start from scratch.

[00:03:32] Let me say that again.

[00:03:33] In most cases, because your old code has the knowledge of time, the knowledge of testing

[00:03:41] over a period of time, and perhaps has a significant number of small changes, small fixes as a

[00:03:48] result of that time tested period.

[00:03:51] As a result of that scenario, it is more likely that you will be successful.

[00:03:56] If you refactor your existing code base, then if you were to rewrite your code entirely,

[00:04:03] rewrite the project entirely.

[00:04:05] Now, the success will depend on a few factors.

[00:04:08] Number one is going to be your testing methods.

[00:04:11] You need to have a robust testing solution for a refactor to work properly.

[00:04:17] Because the reality is you’ve got a code base that may have a bunch of kind of Frankenstein

[00:04:22] features, right?

[00:04:23] You’ve added features over time or you’ve added bug fixes.

[00:04:26] You’ve added exceptions to the rules over time.

[00:04:29] And what you want to do is refactor those Frankenstein pieces into a nicer code base.

[00:04:35] That’s the typical scenario for a time tested five or six year old project that somebody’s

[00:04:41] trying to refactor.

[00:04:42] But the only way that you can successfully refactor a project like that is if you first

[00:04:47] have a way of knowing that your new code is not breaking your old code.

[00:04:51] And that requires some kind of rigorous testing, regardless of whether it’s automated or

[00:04:56] manual.

[00:04:57] But as long as you have a way of verifying that your new code isn’t breaking your old

[00:05:02] code, as long as you have some sort of verification process, then typically you’re going to want

[00:05:08] to choose refactoring over rebuilding.

[00:05:11] Even though it feels good to rebuild, even though it seems intuitively that a new build,

[00:05:17] a fresh code base is going to perform better than the old code base fixed, you’re actually

[00:05:24] going to run into all of the same.

[00:05:26] Problems that you ran into previously, but now you have to rewrite those same bug fixes.

[00:05:32] You have to go through the same knowledge gathering processes that you went through

[00:05:37] over the last five or six years in that previous project.

[00:05:40] You have to go through all of that again.

[00:05:42] Now, of course, there are some benefits to rewriting something entirely from scratch.

[00:05:47] For example, you can build the entire code base test driven first, rather than trying

[00:05:53] to retrofit tests.

[00:05:54] You can take advantage of the.

[00:05:56] Latest software packages.

[00:05:58] But the reality is when you refactor projects, you have the opportunity to refactor into

[00:06:05] those new software packages.

[00:06:08] What this comes down to is shifting your understanding from thinking about physical objects being

[00:06:13] upgraded.

[00:06:14] For example, a car like a 1960s car.

[00:06:17] We think about software that way.

[00:06:19] What we need to do is shift our thinking away from the physical upgrade and to the virtual

[00:06:25] upgrade.

[00:06:26] And.

[00:06:26] Here’s the big difference.

[00:06:28] Refactoring does not mean that you’re sticking with an old system.

[00:06:33] Refactoring doesn’t mean that you’re holding on to all of the Frankenstein components.

[00:06:38] Your existing code base should be treated as knowledge.

[00:06:43] Your existing code base should be treated as knowledge.

[00:06:46] And you don’t want to throw away that knowledge.

[00:06:48] You don’t want to throw away all of that learning that you spent time gaining.

[00:06:53] Your refactor is just as effective.

[00:06:56] If not more.

[00:06:56] If not more effective than replacing the entire system altogether.

[00:07:00] So the truth about old code is that sometimes old code is better than new code.

[00:07:07] Thank you so much for listening to today’s episode of Developer Tea.

[00:07:11] I hope you enjoyed it.

[00:07:11] I hope that it will help you make better decisions about when you should write something new versus

[00:07:18] refactoring something that already exists.

[00:07:20] Most of the time, the kind of TLDR version of today’s episode.

[00:07:25] And most of the time, refactoring is going to be your friend.

[00:07:29] So go forth, refactor your code.

[00:07:31] Thank you so much for listening to today’s episode.

[00:07:33] If you’re enjoying Developer Tea, make sure you subscribe in whatever podcasting app you use.

[00:07:39] It takes just a few seconds.

[00:07:40] If you open up your phone or if you’re listening on a computer,

[00:07:44] open up your computer to whatever app you are using to listen to this episode.

[00:07:48] Go ahead and press subscribe.

[00:07:50] That will ensure that you don’t miss out on future episodes.

[00:07:53] Thank you so much for listening to Developer Tea.

[00:07:55] Till next time, enjoy your tea.

Visão de gráfico