On the Failure of Code Reuse

It has been my experience that there is a direct one-to-one relationship between the quality of a piece of software and how willingly it will be selected for code reuse. This might seem obvious at first if one uses a simplistic definition of what “quality” means. However, quality is not just how cleverly the code implements a particular algorithm, or how efficiently it executes. Quality is much more than these things.

Quality is also determined by the readability of the code. Can it be easily understood? Does it have documentation to accompany it that explains, clearly and concisely, what it does and how to use it? Quality is a characteristic supported by test results. Are the test results available, along with the test cases and procedures used? If these basic things are not in place, then the odds are that the code won’t be selected for reuse.

The upshot here is that code that is not easily understandable is not easily usable or maintainable. One of the main reason that code reuse fails to live up to its promise is that the candidate code itself is so poorly written and so poorly documented that it is easier to just throw it out and start over than to sit and ponder someone else’s obtuse attempt at cleverness. Poorly written and poorly documented code that is not reusable, when it really should be, suffers from what I call “unintentional obfuscation”, and it is rampant in the software industry.

Unintentional obfuscation is what happens when the person writing the code fails to see the need for following an accepted coding style guide, doesn’t bother to document what they’ve done, and doesn’t have a design document to point to that describes, in some fashion, how the code is structured and what it is supposed to do. If they’ve neglected these things then the odds are good that they also don’t have a test plan, test cases or test results to prove that their code works correctly. In other words, it isn’t quality code.

I believe that competent software engineers and developers do understand the value of reuse, but often find it difficult to justify the level of effort necessary to comprehend and validate code that is difficult to read and poorly documented. Rather than beat their head against a wall tying to decipher (and often debug) crufty stuff from some long-gone programmer, they simply throw it out and start over anew. This is not an unreasonable response given a bad starting point. I have myself taken the clean-sheet option on occasion when confronted with nasty legacy code that would have taken longer to bring back to life than it took to just do it over. But no matter how well justified it may be, starting over is still an unfortunate waste of time and money.

0 Responses to “On the Failure of Code Reuse”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow Crankycode on WordPress.com

Little Buddy

An awesome little friend

Jordi the Sheltie passed away in 2008 at the ripe old age of 14. He was the most awesome dog I've ever known.


%d bloggers like this: