Changing the Seldon Plan

…that “if it ain't broke, don't fix it” is also part of the hacker ethics. Modernizing a module for the sole sake of modernizing it - without any evidence of actual problems in it - sounds like a bad idea, worthy of Joel's famous "Don't throw out the code" admonition. ( References: Joel on Software: “Things You Should Never Do, Part I” ; Joel on Software: “Rub a dub dub” . )

I keep hearing and reading this nice proverb if it ain't broke, don't fix it. The latest appearance was in response to Shlomi Fish suggesting that some Ancient Perl code should be replaced by Modern Perl code.

I am not saying that every piece of code should be rewritten every 6 months, but in my understanding that sentence actually translates to let's wait till it breaks and then panic.

I think people who say that sentence are afraid that the new version will break something. Sure, there is always a chance that a change introduces an error, but, if we are afraid to touch the code, what will happen when later on we encounter a case where it does not work? For example, if we need to use it in a new environment. Will we have the courage to change the code then? How much will it cost in money, time, and lost sleep?

I think we have been trying to teach ourselves that we should have really good test coverage of our code and then we can easily refactor it and get rid of technical debt. So why do we keep hearing that sentence?

Hi!

First of all, I should note that szabgab responded below and expanded on it on his blog where he got some comments.

Otherwise, note that ESR does not mention "If it ain't broke, don't fix it." in his summary of the hacker's ethos ( link ). That put aside, it is my belief that if you can invest enough time, you should make sure your code (in whatever programming language or technology that you are using) will follow the best practices. Naturally, and I didn't mention that, you likely need to juggle some other priorities, and cannot spend 100% of your time refactoring and modernising. However, you should invest time doing that because, like Martin Fowler says in his "Refactoring" book, refactoring is a practice that programmers have been doing because it allows them to write code faster and save time in the long run. Without refactoring, the code deteriorates into a very ugly mess, that is hard to maintain, harder to salvage and often becomes non-functional and buggy.

The same is also true on modernising Perl 5 code. Modern Perl has evolved from (and is still backwards compatible to) Perl 1 through Perl 5, and many of features that are still maintained will be happily executed by the interpreter, but are no longer advisable. Doing open FH, $filename is unsafe and wrong, and code without use strict; and use warnings; is also prone for many subtle and hard to catch bugs upon modification. There is no good reason to avoid investing the necessary time and remedying these issues, assuming you do have the time.

The main point I was trying to convey was that you should be confident enough and willing to refactor and modernise Perl code as you encounter it. The person who asked for help in my link did not lack the time to revamp the code - he just wasn't confident enough. While some ancient Perl code is still mostly working fine and can be left alone, you should not uphold any bad code with an aura of holiness. Especially not if you're seeking help with it.

I don't advocate throwing away working code, but even Joel on Software has advocated spending three weeks to refactor existing code, while preserving its integrity along the way. There's a huge difference between refactoring code, and rewriting it all from scratch.

I didn't intend to imply that you should stop everything you're doing right now and modernise and refactor all the Perl code you have and/or use to make it squeaky clean. But you do need to do it if you're constantly using or tweaking it, and please do it before and after you've asked the Perl experts for help on it. That is because we don't know where and how "ancient", non-idiomatic, or inelegant, Perl code will break, and we care too much about code craftsmanship. The issues being discussed are not unique to Perl, but they influence Perl to a possibly larger extent.