Re: When data squared is negative, the data is.................
- From: Arved Sandstrom <dcest61@xxxxxxxxxxx>
- Date: Tue, 08 Dec 2009 10:51:29 GMT
Alan Lothian wrote:
In article <dASSm.90111$VG2.54759@xxxxxxxxxxxxx>, Keith Willshaw[ SNIP ]
<keithnospam@xxxxxxxxxxxxxxxxxxxxx> wrote:
The newer breed of programmer writes very nice user
interfaces in languages such as C++ and C# but the guts are still good
old fashioned F77
When that 30-years-ago generation dies off (can't be long now, unless
my memory deceives me about their shocking personal habits) there's
going to be real trouble. Some still-functioning code goes back farther
than that, too. I have this image of Old Grandad being dragged from his
nursing home in Bournemouth and presented with a huge pile of
yellowing, line-printed code. "Please, old fella, you must remember
something about it. No, nurse, hold back his medication for half an
hour or so."
I've been through a couple of largish mainframe modernization projects now (still stuck in 'em, somewhat), and my general observation is that they are a good idea. Contrary to popular opinion, thirty or forty years ago programming giants did *not* stride the earth and cast pearls of code unto the masses...odds are pretty good in fact that that business code written in the '70's is mediocre, just like it's likely to be today. The code written in the '70's, possibly in a language that was made obsolete thirty years ago, not only requires someone more expensive than your average script kiddie to decipher it, but also may need a senior business user from way back when to review the translation and see if it still applies.
Wait too long with modernization projects, and the danger is not so much that you can't eventually figure out the code (let's assume for sake of argument that we've got source - if you have no source left don't even wait to modernize), but that you have no business clue as to why the code is doing what it very clearly is doing. I saw a fair bit of this occur over the past few years on some of these projects I was/am associated with - "well, we're not entirely sure why this subroutine does that, so the new Java method will do exactly what it does."
Enough of this latter problem - poorly documented code that nobody can trace back to an original business need - and you run the risk of having the legacy code tell you what your requirements are. "Well, back in 1975 somebody obviously thought it necessary to run the PL654TODS313 subroutine every week on the Snarfinex data tables, so until someone now can tell me why we don't have to do that anymore we're going to keep on doing it."
As an aside, I'm starting to lean towards the idea that all you actually modernize is the data itself. Data gets old and crufty just like code does. As for the code, my gut feeling now - wonderful propagandized transformation technologies aside - is that it's cheaper and more reliable to do a greenfield rewrite.
AHS
.
- Follow-Ups:
- Re: When data squared is negative, the data is.................
- From: Alan Lothian
- Re: When data squared is negative, the data is.................
- References:
- Re: When data squared is negative, the data is.................
- From: tankfixer
- Re: When data squared is negative, the data is.................
- From: Keith Willshaw
- Re: When data squared is negative, the data is.................
- From: Alan Lothian
- Re: When data squared is negative, the data is.................
- From: Keith Willshaw
- Re: When data squared is negative, the data is.................
- From: Alan Lothian
- Re: When data squared is negative, the data is.................
- Prev by Date: Re: Military Space Plane = Space life boat?
- Next by Date: Re: China's H-10 stealth bomber secret flight - can carry nuclear bomb
- Previous by thread: Re: When data squared is negative, the data is.................
- Next by thread: Re: When data squared is negative, the data is.................
- Index(es):
Relevant Pages
|