Not long ago, I wrote a post on leveraging code where I discussed the issues of casually throwing code away: “Leveraging Code”
Today, I’ll talk more about when to rewrite the code.
Just yesterday, a couple people happened to ask me how some of my customers decide whether to rewrite their code or to reuse it. As I was responding to that question, it got me thinking more about it and I’d like to share some of my thoughts with readers about this.
Upgrades
When you’re doing an upgrade, it’s uncommon to throw much code away. However, over the years, even the best code gets kind of ratty (yes, I’m trying to wow you with my deep technical jargon!). With all the changes made to some code, even the best practices leave code readable but not as efficient as if it were written from-scratch. At some point, code probably should be rewritten, at least in theory. If it works fine and is efficient, it might not be work rewriting it. After all, rewriting it does mean that the users have to reaccept it with UAT (User Acceptance Testing) because, the larger the block of code, the more potential bugs you’ve introduced in “making it better” by rewriting it. Also, if it’s a regulated system, you’ll probably have to entirely revalidate it.
On the other hand, if it’s getting slow, difficult to understand and make changes to, and truly could use an overhaul on the functionality it delivers, or if it needs to be modified heavily from something used by a single lab or site to something globally usable, then it probably is time to entirely rewrite it.
Differences in Systems
With all that said, there is no particular time guideline I would give on this. I’ve seen systems that are ten to fifteen years old working fine, kind of ratty-looking, but still serving their purpose, and I can’t argue that they probably shouldn’t be touched – that it wouldn’t be cost-effective to do so. And, this is based partly on the fact that the particular software being used still basically hasn’t changed much, in many areas. On the other hand, in the same brands of systems, have seen code that should clearly be removed from the system based on the fact that new modules have rendered them obsolete.
Not Always an Obvious Choice
Even when there are new modules available that do what the old custom code did, it’s not always an obvious choice to replace the old code with the new module. New modules, as feature-rich as they might be, never give the same level of features as the old custom code. New modules always need code added to them. Thus, we are still left with the problem of weighing the amount of work it takes to implement the new module against the extra work of maintaining and modifying the older code.
An Aside
Thank you to those who asked the question of me, yesterday. It obviously helped me come up with a topic to write about and is an important topic to cover.
Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/
And your paragraph “Not Always An Obvious Choice” brings us to something I was taught back when I first learned to program properly in nineteen-umpty-mumble – namely the desirability of writing code in a modular fashion in the first place. One saying I remember from the ‘Algol for Scientists’ course I did (yes, folks, I’m really old enough that I started out on Algol-60) was “If you are in any doubt as to whether a piece of code should be a separate procedure, then the answer is YES!”
Over the years that one concept has saved me more time in doing upgrades than I care to think about.