An interesting metaphor! It is my opinion that software can have a high shelf life if it is properly cared for, but even then, I would expect to see the entire code base "turn over" in time, though some parts of the code would certainly be more stable than others. So, in a way, the basic question is: What does "same" mean? Is a street still the same street if it has been repaved, if new fiber optic cables (or sewers, or something else) have been placed beneath it? If new stop lights have been added? If a subway tunnel has been built beneath it? Of course, the street will not be made of the same "stuff" that it once was (turnover of the code base), it may in some ways be different (wider, stop lights instead of signs, subway stations along the sidewalk, etc.) but we still think of it as the same street. UNIX today is very different from the UNIX V7 I used as a freshman, but we still think of it as UNIX. But if UNIX had not evolved, would it be as important an OS as it is today? --- "K.S. Bhaskar" <[EMAIL PROTECTED]> 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 > ===== A practical man is a man who practices the errors of his forefathers. --Benjamin Disraeli ==== Greg Woodhouse [EMAIL PROTECTED] [EMAIL PROTECTED] ------------------------------------------------------- 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
