On Mon, 29 Nov 2004, 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
