Re^5: At what point do you rewrite that old shell script in Perl?

[mr_mischief]

As for #1, anything that makes a program more maintainable later works. In most cases, rewriting from shell to Perl will help. There are lots of programs in Perl that could stand to be refactored or rewritten in Perl using clearer control flow and more idiomatic usage of the language, too. There are even programs, as flexible as Perl is, that would do well to go from Perl to other languages. There are probably equally as many (or more) IMO that would benefit from going from other languages into Perl.

For #2, I meant that you should compare the time it would take to make your specific change to the amount of time it would take to improve the structure of the program as a whole so that future changes would be easier, quicker, and more manageable. If the time needed to refactor or rewrite the program is less than making the one current change, almost always make the systematic change then add your specific change to the new system. If the two are about the same, you'll probably want to rewrite or refactor and make your change to the new system. Even if it would take longer to make the systematic improvement than to make this single change, think seriously about making the system easier to change rather than just changing it.

By "in the same ballpark", I mean whatever is a similar length of time in the terms of your development process. If we're talking about changes taking an hour, then "in the same balpark" might mean a day. If a change takes a week, then "in the same ballpark" probably doesn't mean 6 to 12 weeks even though that's the same ratio. Saying "I can get you a crufted together update by lunch, or I can give you a clean, high-quality change by tomorrow that will make these changes take mere minutes in the future" will probably go over well. Saying "I'm doing nothing new this quarter because this program that's running just fine needs to be overhauled" will probably not. Yet if you can make the code far more updateable in two weeks vs. making the one change in one week, there's probably a way to convince someone they can wait.

Let's say you are likely to have 9 more changes in the near future. Say it would take x time to make your current changes. Let's say each change would take about the same amount of time, x. That's 10x. Let's say that completely overhauling the system would take 8 times as long as making this change, but it would make further changes take 10% as long because it's trivial to update your newer, cleaner system. That's 8x up front, and 0.9x in the near future. So for a total of 8.9x over ten changes, you've saved 1.1x time. The great thing is, not only have you saved enough time for another task and a long lunch, but the cleaner organization of your program will keep bearing fruit beyond these ten changes if you have further changes in the future. Yet if the one change is needed in production tomorrow due to a change in business process, then taking 8 days to get it done is unacceptable.

If this change you're making is guaranteed to be the last change ever made to your program or suite of programs, then the time to refactor or rewrite it might not be worthwhile. The more changes there will be in the future, though, the higher dividend you get back from making your system easier to maintain. Always, always, when there are changes to be made, consider whether to improve maintainability rather than just doing the maintenance. When in doubt, give preference to the long-term gains of better maintainability.

Any time a project that your need to maintain regularly starts to get difficult to maintain, pick a point at which the next change isn't needed immediately. Take as much time as you can budget between the request and the mandatory delivery time (without impacting other projects negatively) to clean up the system. Make your change against the new, more maintainable system. Ideally, you'd even document the estimate for the new feature in the old version of the system, the estimate against the new version, the actual time it took to code the edit for the new version, and time taken to make the system more maintainable. Use that as justification for more housekeeping work on projects in the future.

If you can't make all your maintainability changes at once (which is likely, since you'll never foresee all the changes requested for an actively changing project anyway), then take baby steps. If the project's in shell, translate it straight into Perl the first time you get a chance. Then, modularize what you can. After that, take all the calls to cut, grep, sed, awk, wc, ls, and similar utilities and use the Perl idioms with the next change request. Then, use Perl's extra flexibility like overloading, hashes, code refs, and more to make the intent of the code and your control flow clearer with the next. The cost gets spread out this way, but the full benefits get realized later rather than sooner too.

Consider architectural changes to the entire structure of the program, but don't get caught in the middle of writing a plugin framework, an event loop, or a scripting engine for your application when you're past due to deliver a simple feature addition.