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
