[Earlier versions of this essay have previously appeared online.]

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, but 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. [The exceptions are when cities are destroyed by war or natural disasters.]

In the not too distant future, a school of thought will likely develop 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 resulting if money is not spent on upkeep when it is needed).

Instead of asking what the life expectancy is of a mission critical software system, perhaps the first lesson is that 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. The history of large software projects is not encouraging, and the growing popularity of agile methods speaks to the higher success rate of evolving software in a series of many small steps versus giant seven-league strides.

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. If we love them, we must love them warts and all.

So, while this brave new always-on networked world does not obsolete our software systems, it does give them an opportunity to evolve or stagnate into obsolescence.