Rewriting Code Rather Than Leveraging It
Written by Gloria Metrick on . Published as written. It may not reflect how these systems work today.
Not long ago, I wrote a post on leveraging code where I discussed the issues of casually throwing code away:
http://outonalims.com/2014/09/16/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/