Legacy Code Can be a Legacy

Very often the term "legacy code" is used in a derogatory sense. The English definition of "legacy" normally has a positive connotation meaning "a gift that is left to future generations." We'll return to that thought later. However, when it is used in the IT community, legacy is often another way of saying "old, outdated, and useless"--at least that's invariably the perspective taken by some speakers/writers. Now admittedly they're often saying it because they have a "solution" to sell but. ...

There are many ways to look at legacy code though. First it's a living repository of the way we conduct our business. Very often it's the _only_ place within our organization where our business rules are recorded (Documentation? We don't need no stinking documentation; we've got code to write!). Our code base also represents a substantial investment in time and effort--often to the tune of millions of dollars. As such it should be viewed as an asset rather than a liability. But an asset only really has value if it can be utilized. While tools can perform business rule recovery (the two tools we know about are Databorough's X-Analysis family of tools and ARCAD's Observer) it seems to us that perhaps this is the biggest "gap" in the toolset that IBM offers to developers on the IBM i platform. Having RDP draw us pretty diagrams of our programs and applications is certainly useful, but being able to extract and repurpose our business rules is what we really need help with. What do you think? Is this the kind of tooling you'd like to see IBM offer?

For many IBM i shops, dealing with their legacy code is becoming an urgent requirement as more and more of us head toward retirement--the economy and our pension plans willing. For some companies this upcoming brain drain is becoming a major factor in considering a move to an alternative platform. Not that that's necessarily a solution either. Today's state-of-the-art application is tomorrow's legacy code after all. Witness the many "Is Java a Legacy Language?" articles on the web.

Personally we'd like to think that what we leave behind when we retire won't quickly be consigned to that negative legacy category. To help ensure that, we're trying harder to make sure we document what we do both internally and externally. We're trying harder to get clients to install appropriate tooling to help ensure maintenance is effective and accurate. And above all we're trying to ensure that we use modern programming practices when writing new programs to help ensure they can be readily repurposed. Indeed we're also trying to avoid the "just one more little fix" mentality and rewrite programs when appropriate. After all, rewriting may take a little longer than adding more chewing gum and bailer twine to an existing program, but it will reduce the time taken to perform any subsequent modifications.

Remember--today's masterpiece is tomorrow's legacy. Don't make the kind of mistake that Jon once made where inadequate documentation and poor error messages resulted in a gentleman in Hong Kong having to undertake a two-week search to track him down to discover the true meaning of the message "Oh xxxx - the xxxx thing has done it again!" 

Comments

[Aaron Bartell]

> "Oh xxxx - the xxxx thing has done it again!"

That gave me a good chuckle.

Why the xxxx? Are you guys getting censored by SOPA? ;-) [can of worms status: OPEN]

AaronBartell.com

[Jorge Gutierrez]

This article came to me so "write on time" that it's scary! Sometimes it feels like you guys are reading my mind, I'm not exaggerating.

"Complexity Management" is the name of the game, and you've described it very accurately.

Jorge

[Dan Devoe]

"Remember--today's masterpiece is tomorrow's legacy."
 
For years, IBM, various software vendors, & others have been attempting to get shops to develop "more modern" looking applications.  Many shops have been hesitant to do so for a number of reasons, including, but not limited to:

* The current business logic works - if it ain't broke, don't fix it
* The amount of hours & cost to modernize applications
* Application life cycle
* Picking an interface that will be updated/modernized by the vendor, and will not be abandoned, leaving newly developed masterpieces to become modern-day legacy applications
 
We had a few products that we were considering moving towards, but ultimately decided on VisualAge for RPG.  The question had been asked by myself & others, about IBM's commitment towards supporting VRPG.  We were given assurances that IBM had no intentions of discontinuing enhancing VRPG, and planned on supporting it for many years.
 
We found VRPG very easy to use - after all, it is essentially the same language (with GUI enhancements) that we'd been writing in for years.
 
Shortly after we started writing our first application, rumors started flying that IBM was going to cease development of VRPG, and end support.  When I questioned a speaker at a local conference about this, I was assured that you cannot believe everything that you hear, and that IBM is committed to VRPG.
 
So development continued in our shop...
 
Within a year, IBM officially ended support for VRPG.  When I questioned two speakers at a local conference (who worked for IBM), the subject was taboo.  When questioning them about a migration path, the ultimate answer was that there wasn't one (although a year or two later, EGL was proposed as a possible solution).
 
So here we are with some brand new, "mission-critical" core business applications, utilizing an easy-to-use interface that the users liked, that are now considered by IBM to be Legacy.
 
I'm thinking to myself - how could a development tool, which supports the modern (I believe up to 6.1) RPG compiler syntax - including free-form, be considered to be "legacy"?
 
A few years pass, and now a new wrinkle - these once "modern" applications would no longer run on Windows 7 (64-bit).  Sure, there is XP Mode within Windows 7 Professional, but deployment is messy.
 
And IBM was no help, because VRPG is no longer supported, and was never supported on Windows 7 or Vista (although I never had an issue running on a 32-bit Vista machine - even for development).
 
Finally, after lots of experimentation, I was able to successfully get VRPG applications to run in native Windows 7 mode.  Maintenance/development of applications still needs to be performed through XP mode, but that is a small price to pay to be able to maintain these now-legacy (although still newer than our ERP solution) applications.
 
I know that we are not the only shop in this boat, so I contacted a local IBM i publication, to let them know of my success in being able to run VRPG applications in native Windows 7 mode, and inquired if they would be interested in an article explaining how to do so.
 
Their basic response was that there wouldn't be enough reader interest, and that since the product is no longer supported by IBM, they wouldn't consider publishing it.
 
Hindsight is 20/20 - we made a poor choice in attempting to develop modern applications.  But unfortunately, we do not presently have the time or resources to move our existing VRPG applications to another platform.  Perhaps Windows 8 will prove to be the ultimate dagger, where these applications will not run at all.
 
Its too bad that the "legacy" of these applications will not mean "gifts that are left to future generations."

[Nathan Andelin]

"Perhaps Windows 8 will prove to be the ultimate dagger, where these applications will not run at all." Dan Devoe.

It sounds like you can pretty much count on that. Based on rumor, of course ;-)

People at IBM started a discussion at RPG Cafe a couple years ago about continuing support for VARPG, but it appeared that the community who were using VARPG were adamantly against any ecosystem that would allow IBM to make a profit, or even cover their costs. There would be no money for IBM in it.

Why would IBM continue supporting a product that helps people move applications off IBM i, to Windows. And offer's nothing in return?

[Dan Devoe]

"People at IBM started a discussion at RPG Cafe a couple years ago about continuing support for VARPG"

I remember a post by someone at IBM, in the RPG Cafe, regarding defining the future of VRPG.

The post started off by stating how VRPG is a product that IBM is extremely proud of, is looking to enhance, etc., etc.

As it was, this post came out around 2 weeks before I attended NEUGC in Framingham, MA. There were at least one speaker from IBM there, who was involved directly with the enhancement of RPG.

So I questioned him about VRPG, and he informed me that VRPG is "dead". When I pointed out this post in RPG Cafe, he got quite hot under the collar. A few days after the conference, the post had been removed.

At some point in time, I'm sure that we'll be migrating towards a more modern "modernization" tool (perhaps RPG OA). But, one reason why we learn history is to learn from the mistakes of others.

We went down a modernization path before, only to have the rug pulled out from beneath us. Whose to say that it won't happen again.