How to prevent code rot - Web Development - Techguide

How to prevent code rot

 

Summary

Software developers call neglected code that stops working code rot. Chip Camden explains why this often occurs and how to avoid such trouble.

Events

Echelon 2012
June 11 and 12, 2012

University Cultural Centre, National University of Singapore

Startup Asia Jakarta 2012
June 7 and 8, 2012

12th Floor, Annex Building, Wisma Nusantara Complex, Jl. M.H. Thamrin No. 59 Jakarta 10350, Indonesia

MMA Forum Singapore
April 23-25, 2012

Grand Hyatt Singapore

I sat alone eating breakfast at my favorite diner. The cook ambled out of the kitchen to the soda machine to fill her cup with ice, but she couldn't get any out. She called the owner, who came out of the back and fiddled with the machine a couple of times before it finally gave ice. "It just wanted some attention," she said as she left.

A system that needs periodic attention indicates poorly designed automation, I thought to myself. Yet, most systems do seem to require this kind of babysitting. If someone cares for the systems on a regular basis, they run indefinitely without a hitch; if the systems are neglected for too long, they fall apart.

In software development, we call that code rot. When nobody pays attention to a section of working code, it suddenly doesn't work any more. Sometimes after examining the problem, I conclude that it could never have worked--despite the fact that it had been running for years. This happens so frequently that it almost doesn't surprise me any more. The code didn't change itself (at least, most code can't do that), so how did this happen?

You might suspect that the metaphor "rot" is somewhat inaccurate. Physical materials degrade spontaneously--or do they? If you could place a tomato in a sealed environment and remove all microbes from it, it wouldn't rot. Nothing rots by itself--it needs some agent acting on it.

While extending a metaphor doesn't establish fact, it seems to shed light on this case. Code rot often occurs because the requirements for the code have shifted imperceptibly--as imperceptibly as bacteria infect organic matter. Nobody remembers that the environment in which this code operated successfully for years differed subtly from that in which it is now expected to function. Changes made elsewhere place new, unforeseen, and undocumented demands on this code. Common sense says that it should handle this case, but nobody thought of that specific combination of circumstances when it was designed.

Code can also degrade because it relies on the behavior of other code. The documented behavior of a library or framework often doesn't include specific details on which clients rely. The author may feel free to change an undocumented behavior--he or she may even consider it a bug. Combine a few of those changes together, and you can easily lose the trail back to "how did this ever work?"

What can we do to prevent code rot?
We can take another cue from our metaphor: avoid exposure, because exposure hastens rot. The less your software relies on other software, and vice versa, the less trouble you'll have. By "less", I don't mean fewer instances of usage, but rather fewer methods of usage. Consider the Unix 'tee' utility, for example. Other than the obligatory proliferation of GNU options, it hasn't changed significantly in decades, and yet, it doesn't rot. Why? Because from the beginning it defined a simple interface with clear expectations. Furthermore, it confines its expectations of the code on which it relies (the standard C library) to clearly documented behavior in the purpose for which it was written.

Documentation helps, but documentation is not the solution--simplicity is. Now matter how well-documented the system, if it has too many interdependencies with other systems, some of those dependencies will change in incompatible ways. Therefore, break the system down into simple, independent components that each do one thing well, and document those things. As requirements change, the alignment of those components may need to be altered, but not so much the components themselves.

You must employ discipline to stick to that philosophy. When a new requirement arises, don't give in to the impulse to just hack in support for this special case by passing in a flag. That will introduce additional, unnecessary complexity to the interface. The more you do that, the more likely you'll create a web of unseen interdependencies that will lead directly to rotten code.

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.

Talkback

Add your opinion

In order to post a comment, you need to be registered. (Sign In or register below)

Post your comment

ZDNet Asia Live

Alibaba seeks $2.3B from shareholders for Yahoo deal http://t.co/ySyCwLvJ via @zdnetasia

Rise in Chinese-funded acquisitions could trigger more hurdles: By Ellyne Phneah , ZDNet Asia on May 22, 2012 (6... http://t.co/L4QzDq3H

Kodak loses patent ruling against Apple, RIM - ZDNet Asia http://t.co/O7P8U2Ya

Rise in Chinese-funded acquisitions could trigger more hurdles - ZDNet Asia http://t.co/WJCfhWLs

Kodak loses patent ruling against Apple, RIM. http://t.co/N1j7aZ6o

#radio Radio Serbia by EnjoyIT 1.0 http://t.co/nGQFvX2E

Rise in <b>Chinese</b>-funded acquisitions could trigger more hurdles http://t.co/0pXBS1HR

Rise in Chinese-funded acquisitions could trigger more hurdles: By Ellyne Phneah , ZDNet Asia on May 22, 2012 (6... http://t.co/W3SOdw2c

RT @zdnetasia: CFOs increasingly involved in IT investment decisions. http://t.co/8QrfwOSb

CFOs increasingly involved in IT investment decisions http://t.co/XD1LerFq via @zdnetasia #PrivateCloud #SC2012 #CAPEX

Rise in Chinese-funded acquisitions could trigger more hurdles. http://t.co/VC3G3m3o

RT @zdnetasia: Rise in Chinese-funded acquisitions could trigger more hurdles. http://t.co/VC3G3m3o

So much as we know , MTK6575 extremely integrated frequency1GHz ARM Cortex-A9 processor, the superiority of 3G / HSPA Modem, and help the...

2 hours ago by y15822137359 on 5 SaaS adoption speed bumps to avoid

Rise in Chinese-funded acquisitions could trigger more hurdles - ZDNet Asia: Rise in Chinese-funded acquisitions... http://t.co/bZaAQnRL

Rise in Chinese-funded acquisitions could trigger more hurdles http://t.co/mIsuZjnU http://t.co/erFX4aVv #arcavir

http://t.co/VNaZtseV Rise in Chinese-funded acquisitions could trigger more hurdles: "Cash r... http://t.co/N0gZZEdR http://t.co/wiqY9ktt

I reckon your view: "CRM is strategy, not software", if a company replicating the approach uses in ERP implementation into CRM, what they...

1 day ago by wykoong on Gartner: Mobile CRM gives better ROI than social

This video will teach you about the Excel fill handle but also provide you with a workook to download... http://www.youtube.com/watch?v=...

1 day ago by TradeBrother on A quick fill handle trick for Microsoft Excel

waiting...

3 days ago by eapete on What should count in a company's market value?

Boy, you've opened a can of worms now.

Wait for the rants & raves.

3 days ago by eapete on What should count in a company's market value?

I was puzzling before this whether to replicate the success formula we executed for a financial institute, and come out with a standard s...

4 days ago by wykoong on Drop the egos, copy ideas, then innovate