I originally wrote this up as a reply to this excellent comment on the MUMPS thread [1]. Since that thread is getting exceedingly long, I decided to start with a new post here--and anyway, I'm basically changing the subject away from MUMPS in specific and more towards some of the other painful realities (and ironies) illustrated in the aforementioned comment [2]. This excerpt tells the tale:

MUMPS applications are likely to remain in place simply because it would take a very long time to create solutions that replicate the 30 years worth of features. At best, it would probably take 5-10 years of *transitioning* between MUMPS, a MUMPS/SQL hybrid and then SQL-only to achieve a pure SQL solution. During that time, few new features or extensions would be able to be added to the application since the developers focus would be on transitioning. The end benefit would be a system that new programmers could immediately start working on and in a language that offers modern features. Future development from that point would be faster and more efficient. Still, the administration is unlikely to back this scheme since they won't want to pay a team of programmers 5-10 years to "run the red queen's race" and the programmers won't want to do it since they'll see it as an effort to make them replaceable.

Ouch. There are real challenges like this one facing the software world related to long-life applications, both the ones we're stuck with (or, to put it another way, the ones that have been serving us well all these years) and the ones we've yet to build. I see it as two sides of the same coin, in a way, the first side being, How we are going to effectively manage an aging fleet of systems and a retiring workforce of programmers? The second side is, How can we do better at building systems from scratch that are likely to have long lifetimes? How can we *plan* for decades of use?

When software applications have a life span measured in decades, the dynamics change. Looking back to 60's, it's easy to be forgiving of the people who developed the solutions that have stayed in production since then because the idea of decades-long use might not have been conceivable. I wasn't there, and who am I to second-guess. But now that we know that decades-long application lifetimes are a reality, how are we as a profession addressing this need? How are we advising our clients?

What are the favored techniques for designing for decades? Is this an explicit topic on which people have researched and/or published? Language, tool, and platform choices seem like key factors. Is "roll your own" from top to bottom the only way to ensure longevity? Or is the adoption of "open" standards and technologies protection enough from market-driven innovation cycles?

One recent place I recall this topic coming up is Pete McBreen's manifesto Software Craftsmanship [3], which, while flawed in some ways, is a worthy read. McBreen tackles explicitly the topic of taking a perspective as software craftspeople on how we can build systems that will really last for decades.

And of course I've so far ignored the question of whether companies and governments would be willing to pay up front to design and build a new system with decades of use in mind (not to mention the complications raised in Saintly's comment for situations in which one decades-old system must be replaced with a new one that will live just as long!).

Didn't Frederick Brooks say "Plan to throw one away."?

Thanks for reading,
Dan