Skip to main content

Coding for your own legacy

Posted by johnreynolds on April 30, 2004 at 6:26 AM PDT

I fear that most programmers (myself included) usually think of the word "legacy" as something bad, as in the following article:

Do your customers have legacy COBOL applications written around the time King Nebuchadnezzar II built the Hanging Gardens of Babylon?

Legacy doesn't have to be a bad word, as is seen in The American Heritage® Dictionary of the English Language:


Something handed down from an ancestor or a predecessor or from the past:

"a legacy of religious freedom." See Synonyms at heritage.

What are you doing today to insure that the programmers of tomorrow don't curse that @#%!! legacy Java code that they're stuck with?

Based on my own astute powers of observation (and my gut feelings), I will hazard to publically predict that the programmers in the distant future (say five years from now) will not all be using Java. I further predict that the many programmers who will be using Java will not be using the primitive dialect that we currently employ.

With this limited knowledge of the future, how can I increase the odds that my coding efforts will be appreciated rather then cursed? To answer this question, I took a look at my least favorite legacy "assets" and tried to put my finger on what annoys me most.

Many of my least-favorite legacy applications have poor documentation. If you want to make a future programmer happy, explain what your code does and how to use it in clear and concise terms.

Hard to generate inputs and hard to parse outputs are guaranteed to produce expletives rather then praise. I once wrote a "survey" application whose output was serialized C++ objects. A companion application, also in C++, reinstantiated the survey objects to populate a database (The "surveys" were mailed to consumers on floppies. When the consumers mailed the floppies back, the results were retrieved). This was a great idea until the company switched to Java. If I had added code to produce ASCII output (this was pre-XML days), I would have been cursed less often. Efficiency does less to assure a good legacy then interoperability.

Several of my least-favorite legacy applications are bound by Graphical User Interfaces. GUI applications are notoriously difficult to integrate with anything else (see the blog by Rich Burridge for specifics): Contrast reusing GUI applications with reusing the CLI shell utilities that are so prevalent in Unix environments. I'm not suggesting that GUI interfaces aren't appropriate, just that life is easier when designers include command-line interfaces or programmatic APIs to access the core functionality.

Finally, my least-favorite legacy assets often do more then they need to. Sometimes the programs have bizarre side effects, but often the problem is that the original designer didn't distill the functionality to its essence. It's like having to pay for a reverse-osmosis purification unit when all you need is a water heater.

We can't guarantee that our heirs will value our code, but with the benefit of hindsight we can improve the odds.

All this leads me to think that embracing the Service Oriented Architecture paradyme will reduce the chances that I will be burned in effigy some day. SOA is defined in an IBM article as:

SOA is - "an application architecture within which all functions are defined as independent services with well-defined invokeable interfaces which can be called in defined sequences to form business processes."

The experiences that Calum Shaw-Mackay relates in his blog on The Great Theoretical Architecture resonate strongly with my own. His distilled design mantra is simple:

"this is my service it does X, and when you tell it to do X with this data, it does something and gives you this back"

Perhaps if I design my applications with "service orientation" as my guiding principle, then the legacy of code that I pass on will be appreciated instead of endured.

(Cross posted at The Thoughtful Programmer)

Related Topics >>