Legacy (common usage)—Money or property left to someone in a will (source: Oxford Dictionary). Legacy (IT usage)—Code that should be replaced, generally with code that might be equally as old but is written in a different language (source: me).
I think I must be entering the curmudgeon phase of life, although some people say that's where I've been for the last 20 years. But some things bug me, and my hope is to get them to bug you just as much. And one of the things that bugs me more than anything else is the way we throw around the word "legacy" as in "Oh, that's legacy code. Don't touch it; you'll get hives."
What I'd like to know is when did the word "legacy"—something that every father in Victorian England considered invaluable to leave to his family and that Dickens used to admirable ends in Great Expectations—become something foul and disgusting?
But for the last 20 years, the worst IT or business insult you could throw at someone was that their system was legacy.
Gasp.
Yes, it was the kiss of death. The tribunal, the IT overlords, and the pundits decided that such a piece of software, whatever it was, was no longer deserving of grace. It had lived past its lifetime, and no matter what problems you were having (inability to take in orders quickly, poor inventory accuracy, crappy shipping data, whatever), the real problem was that the software you were using was legacy.
What Is Legacy?
Legacy—A gift of property, as money, by will or bequest. Anything handed down by ancestor or predecessor.
That's what the American College Dictionary, copyright 1958, had to say about the word "legacy."
And I guess, to be fair, that part of it is being carried forward in the new IT definition of legacy. It is code handed down that you're now using. You might have developed it yourself, but generally it's been around for a while.
What has changed is the connotation. Historically, a legacy was something good. Nobody seemed particularly upset because they left or received a legacy. Today the connotation is totally negative and not just negative but fatally negative. It's code that needs to be replaced three years ago, code that's toxically dangerous, and the sole reason that your company is not excelling.
Where Did Legacy Come From?
Like most great plagues, the concept of legacy did not originate in only one place.
Some buzzologists (scientists who study the history and entomology of buzzwords) claim that the term first surfaced in the turmoil and carnage preceding Y2K, where people who were working on modernizing code to handle the new century began to refer to code that was not Y2K-compliant as "legacy code."
This definition was quickly converted to a more general statement about code that had been around for a while. And the surprising implication was that this was a bad thing. Of course, this wasn't the first time that business people have taken a word and completely reversed its meaning, but it was one of the big ones.
Once a new buzzword appears, the next group that generally pounces on it are the journalists (if we may use that word loosely), the people who write articles and blog posts on technology and how it affects us. (I don't qualify because too few people read my stuff.) Their stock in trade rests on always being on the forefront of the technology curve, so they jumped all over this new use of an old word. While their efforts might have been noble at heart, any time you suddenly see a herd of articles all on a new thing, you naturally begin to think it's important and that there's something to it.
But the people who deserve the most credit are the marketers who used legacy as a wedge to separate what was out there from the wares they were offering. In many cases, software that was being sold was as old as or older than the software they wanted you to replace, but the word "legacy," when applied to your code, made it OK. Their stuff was never legacy because a) you didn't own it yet and b) if you did, then all you had to do was upgrade to the newest release.
What's Wrong with Legacy?
The real problem with legacy is how we react to it.
If you ask a group of people how many have been exposed to a sexually transmitted disease, very few hands will go up. But ask them if they have legacy code and quite a few will happily throw their system under the bus and raise their hands. Why? In some ways, the legacy confession is a way of transferring responsibility from you to your system for the fact that your system is not all it should be. "Oh, we can't possibly be held responsible for the state of our system. It's legacy code."
Sorry, but that's a total cop-out. I don't care if it is legacy code (even if having legacy code were a bad thing, which I don't believe). We're all still responsible for the state of our systems because we're still the only ones who can change that state. The code can't do it on its own. The code doesn't control us; we control the code.
And that brings us to the other problem with how we respond to the legacy accusation. Generally, people respond not by fixing the code they have but by replacing it. Yep, can't do anything with legacy code except haul it out to the dumpster and throw it in. I need brand new code that can immediately start depreciating like a '64 Chevy Nova.
The real issue here is that for us in the IBM i world, what we generally replace our legacy RPG code with is something written in a language other than RPG and often something that runs on Windows (and how old is the Windows kernel?) so that the final result is to expand the language coverage that you need to supply plus weaken the business rationale for staying with the i.
What We Have to Stop Accepting
So what do we need to do? Well, we need to stop taking this lying down.
First, maybe we need a new definition of what "legacy" code is. We're not going to do away with the term. It's too embedded in the IT language at this point. And we can't change the way people think about the term, no matter how inaccurate it may be in terms of the real meaning of the word.
The truth is that today anything you have in production is liable to the legacy tag, and we need to stop accepting that and instead define it as "code that no longer fulfills a business function or that is dangerous to execute." With this new definition in hand, we then need to re-evaluate not just our RPG code but all the code we have (including our Microsoft Server 2003 installations).
And what should we do with the real legacy code that we do find in the RPG house? Rewrite it, of course. Rewrite it in /free. Rewrite it as modular, ILE, service-program-oriented code. Rewrite it with increased business functionality that enhances and complements your business system.
Yes, we have legacy code. And we're happy with that because only legacy code allows us to fully support our business in the way that we need to for our company's direction. Got a problem with that?
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online