Legacy Code: Avoid, Fix, or Flee (Two Out of Three Mean Forget It)
December 4, 2024
In his Substack post, “Legacy Schmegacy,” software engineer David Reis offers some pointers on preventing and coping with legacy code. We found this snippet interesting:
“Someone must fix the legacy code, but it doesn’t have to be you. It’s far more honorable to switch projects or companies than to lead a misguided rewrite.”
That’s the spirit: quit and let someone else deal with it. But not everyone is in the position to cut and run. For those actually interested in addressing the problem, Reis has some suggestions. First, though, the post lists factors that can prevent legacy code in the first place:
- “The longer a programmer’s tenure the less code will become legacy, since authors will be around to appreciate and maintain it.
- The more code is well architected, clear and documented the less it will become legacy, since there is a higher chance the author can transfer it to a new owner successfully.
- The more the company uses pair programming, code reviews, and other knowledge transfer techniques, the less code will become legacy, as people other than the author will have knowledge about it.
- The more the company grows junior engineers the less code will become legacy, since the best way to grow juniors is to hand them ownership of components.
- The more a company uses simple standard technologies, the less likely code will become legacy, since knowledge about them will be widespread in the organization. Ironically if you define innovation as adopting new technologies, the more a team innovates the more legacy it will have. Every time it adopts a new technology, either it won’t work, and the attempt will become legacy, or it will succeed, and the old systems will.”
Reiss’ number one suggestion to avoid creating legacy code is, “don’t write crappy code.” Noted. Also, stick with tried and true methods unless shiny a new tech is definitely the best option. Perhaps most importantly, coders should teach others in the organization how their code works and leave behind good documentation. So, common sense and best practices. Brilliant!
When confronted with a predecessor’s code, he advises one to “delegacify” it. That is a word he coined to mean: Take time to understand the code and see if it can be improved over time before tossing it out entirely. Or, as noted above, just run away. That can be an option for some.
Cynthia Murrell, December 4, 2024
Comments
Got something to say?
-
- Subscribe to Beyond Search
Feature archive
News archive
-
