Jim, this is a wonderful analogy. And I agree with the consequences for program life. I am told there are still IBM 1401 (Autocoder) programs used in emulation ...
BTW do you know of any study of the reasons why huge systems failed? I am trying to understand why German megaprojects failed. Wolfgang Giere "K.S. Bhaskar" wrote: > I am motivated to repost below something I wrote a couple of years ago. > My apologies for any repetition, but I think it is relevant. > > I would like to question Greg's basic assumption that code has limited > "shelf life". Code that is deemed obsolete will indeed have limited > shelf life, but code does not inherently have shelf life. The question > to ask is what it takes to keep code viable with no planned end of life > rather than what the shelf life is of the code. > > Why should a system that is working well need to be replaced? > Successful software systems are like cities. There are cities > in Europe that have been continuously inhabited for thousands of > years. London or Rome today would be unrecognizable to Julius > Caesar, yet the old cities were never abandoned and replaced - > they were just continuously re-developed over the centuries. > Although we like to discuss replacing major software systems > because their quirks annoy us, perhaps we should think of these > as limitations that must be lived with, just as in these days of > the automobile, we still deal with streets in Boston that were > engineered for horses and wagons, and we have no intention of > razing and rebuilding downtown. > > The prospect of "big-bang" conversions of large mission critical > software systems gives CIOs ulcers just the way that the > prospect of razing and rebuilding downtowns gives city fathers > ulcers. > > I suspect that in the not too distant future, a school of > thought may evolve to the effect that large software systems > will not only not be replaced, but also that we should not plan > to replace them. Just as we may tear down buildings and build > highways, perhaps we should not think in terms of replacing > large software systems, but in terms of a process of continuous > modernization and renewal (with the software equivalent of urban > decay if money is not spent on maintenance when it is needed). > > Perhaps the first lesson is that instead of asking what the life > expectancy is of a mission critical software system like VistA, > perhaps it is more meaningful to ask what it takes to keep it > healthy and contemporary on an ongoing basis. > > Cities evolve. With a few notable exceptions of seats of > Government, cities are not greenfield creations. They start > small, and grow, and what they are good at changes over time. > > So the second lesson for software is probably that mega projects > that try to do everything are almost certainly doomed from the > start. Although I have no personal knowledge of the failed > Kaiser Permanente application, it would seem to be of this > nature. The history of attempts to replace VistA variants > (e.g., CHCS at the Department of Defense) are also not > encouraging. > > Rome was not built in a day. > > A third lesson from the analogy is that, since large > applications evolve, they will always have aspects that are > obsolete and awkward. So, if we love them, we must love them > warts and all. > > -- Bhaskar > > On Mon, 2004-11-29 at 10:53, Greg Woodhouse wrote: > > My take is that the basic assumption is that code has limited "shelf > > life"; i.e., that there is a point beyond ewhich continuing to patch > > the same code without reriting it is counterproductive. If you grant > > this assumption, then the next question becomes: What technolog(ies) > > should we use in our next rewrite? That leads logically to another > > question, which is: What are the advantages and disadvantages of using > > a given technology? This is where I think we have failed to make the > > case, because so often the issue is framed not in terms of what > > advantages there are in using M(UMPS), but whether a significant > > rewrite is needed at all. > > *************************************************************************** > This electronic mail transmission contains confidential and/or privileged > information intended only for the person(s) named. > Any use, distribution, copying or disclosure by another person is strictly > prohibited. > *************************************************************************** > > NOTE: Ce courriel est destine exclusivement au(x) destinataire(s) > mentionne(s) ci-dessus et peut contenir de l'information privilegiee, > confidentielle et/ou dispensee de divulgation aux termes des lois > applicables. Si vous avez recu ce message par erreur, ou s'il ne vous est pas > destine, veuillez le mentionner immediatement a l'expediteur et effacer ce > courriel. > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Hardhats-members mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
