I was reading CIO update and noticed an article titled, “IT Needs a Culture Change”. The article talks about the problem of loads of legacy COBOL code (180 billion lines of code) and few, if any, programmers (they’re retiring) to keep it working. The article goes on to say that the problem of legacy systems is much greater than just COBOL programs. The problem is in everything that has a longer life than planned without the people to keep it working. Similar problems exist for some old automobile or airplane maintenance workers. Same problem for trying to fix obscure appliances that repair people don’t handle anymore.
I was surprised to learn that soem code and systems that I had built back in the 1970’s was still being used at the turn of the century. The Mars Rovers are still running around the planet after 3 years (their original project plan called for the rovers prime mission to be 90 Martian days) - "NASA Mars Team Teaches Old Rovers New Tricks to Kick Off Year Four". Wonderful engineering marrying hardware and software can do amazing things and be productive/useful for a lot longer than originally planned (or desired).
Is a legacy application one that is installed? What are legacy tools? If the software and tools are useful for real work, does this mean they are not legacy? Recent programmer survey results show that a good percentage of developers are still supporting older applications even while they work on new software. Is there a different legacy definition for Internet applications? It seems like today’s modern mashup is yesterday’s old Web application the day it is deployed. One of last month’s Google developer news was “Google Deprecates their SOAP Search API”. APIs, interfaces, WSDL definitions change or are deprecated (I love that term “deprecated“) before most developers have the chance to take advantage of them.
Who can keep these sytems up and running, especially when there is new work to be done? Such is the resilience of software and the work that we do. Should “legacy” be defined into systems at the beginning? Should we propose a “software death” requirement at the beginning? Should we force the replacement of software systems by having built-in shut down dates?
Maybe we need to add a new method to an application object like:
Application.EndOfLife(self,EndDateTime);
Or add a language statement like:
When Application.Type.Language.Programmers = 0 then Halt(Forever) otherwise KeepRunning;
{ 4 } Comments
Great POST!
My experience in IT department:
1. Legacy applications are used for daily work.
2. Legacy applications need a lot of maintenance to run
3. It’s very, very difficult to change application logic in old (1982) COBOL programs!
4. New employees want new Software features (drag & drop, cut & paste, office integration…) NOT available in 1982 software!
5. Application Logic is so embedded in code that It’s impossible to understand. (=Spaghetti Software)
I think it’s important to understand if an application must be open to external software. If it’s closed (for example low level application running on PLC) there is no need to maintain it so much as a "live" application.
A legacy app definition is maybe one that has not yet got enough money budget to put lots of programmers working to renew or port it completely to new technologies. It makes much more sense to put the money and efforts onto developing new stuff, if the old apps are still working fine. Maybe that’s why holy-grail language+api automatic converters dont get too much attention… <gg>
If there was enough business demand, many people would have maybe released just-one-click magic converters that would rewrite all your code,forms,etc into new languages or frameworks.
Having spent a number of years with both Delphi and a COBOL editor open concurrently, I see no difference between them.
I am hoping to re-define "legacy" in a few months to mean any application where the code was written by hand.
This issue came up at our software company very recently. Almost 3 years ago we were aquired and a new layer of management was brought in with of course a Microsoft zipperhead mentality. Our product had been thriving from 10 years of Borland technology, but since it didn’t have a pool of millions of MS developer resources, a change was neccessary. They immediately branded the Delphi product as Legacy and began the process of rewriting the application. Their heads were so far up their netherlands, they refused to even look at the "old" application, even though over 24,000 users loved it. It was not a .Net hosted service, so it must be aniquated…
Well, that was years ago and the C#.Net team has yet to produce anything deliver a product, and yet we’re still called Legacy. A company wide email went out to list a job opening in the Legacy product department…this was the first time the term was used in a public broadcast. My staff of 8 was more than a bit ruffled. Many emails bantered about with legacy definitions and good rebuttles. Several of the definitions were: "an existing application program which continues to be used because the user does not want to replace or redesign it", "potentially problematic since they run on obsolete (and usually slow) hardware, and spare parts for such computers are difficult to obtain", "These systems are often hard to maintain, improve, and expand because there is a general lack of understanding of the system", "The designers of the system may have left the organization, leaving no one left to explain how it works", "inadequate documentation or manuals having been lost over the years", "Integration with newer systems may be difficult due to different technologies."
We responded to every issue. Our application is being designed and redesigned based on current user feedback, Delphi does NOT require slow obsolete hardware, as a matter of fact it runs on the full range of machines from Win98 to Vista, 64 Meg P3s to 64bit OS’s. There is not a lack of understanding of "Windows" (DUH), the designers have not left the organization (I’m still here and coding as fast as ever), and we have proven to be able to integrate with the new technologies. I for one refuse to be considered Legacy simply because we’re not written in a Microsoft language.
I’m backing CodeGear as a huge Delphi fan and plan to outperform the Microsoft guys at every opportunity!
Randy
Post a Comment