Software Life Cycle

Putting aside the develop stage of software which is covered elsewhere in SystemsDevelopmentLifeCycle, it is important that we notice the life cycle patterns of software. Despite the hackneyed joke that software is obsolete at the time that it is released, we can gain much from looking at what software is short-lived, and that which becomes legacy software. This study definitely must include operating systems and programming languages, software objects whose life cycle is easily tracked.

Let us take, for example, DigitalEquipmentCorporation's VmsOperatingSystem. It was brilliantly engineered for Digital's (at that time, DEC's) target market. Unlike UNIX, the quintessential ad hoc operating system, VMS was engineered (please don't use the word "architected") to be dependable and capable of being managed through its plethora of operations instrumentation and management levels. It wasn't just the VAX cluster concept that sold VAXs, it was the operating system.

Today, VMS is no longer the popular OS that was, though it is an important source of revenue for Digital. But even there, UNIX is king (with MicrosoftWindowsNt a strong contender).

VMS continues to survive, in fact even be requested in new orders. This is mostly from the huge repository of FortranLanguage and CobolLanguage applications that were written specifically for VMS platforms.

(You may incorporate your thoughts directly into this block of the document, or I will extract from your responses. -- BenSmith)

Software needs to live, breathe, intake energy (from its designers), grow -> or else wither. It is always growing or withering, never static or stable. This is part of the life-cycle story. (AlistairCockburn)


I have designed and seen designed lovely software which did not get the post-partum, constant breathing. We thought that the design was good and stable, and (were not actually surprised when we) discovered that is not enough. -- AlistairCockburn


The last phase, Extinction, need not occur in our lifetime. Though the generations of software may occur in 18 months or less, the usefulness of a software product can extend over hundreds of these generations if support, improvement and relevancy to the current environment of software use is maintained. See TimeBoxing.

PlannedExtinction? as practiced for the purpose of generating a resale of software which is a natural follow-up, is not truly extinction, but rather improvement of the product which has been systematically abandoned. Prime examples are represented by AutoCad and MicroSoft and the marketing plan which promotes repurchase of the improvements as "upgrades" or "new products". This is a SuccessOrientedApproach which aims at a method of financing Software Improvements by means which have proven successful when "real" rather than "hyped" improvements occurs. For software to have a long life, it must minimize its dependence on platforms and equipment which are likely to fade into obsolescence and abandonment. -- MarkRogers


See also LehmansLaws


CategoryTime


EditText of this page (last edited March 29, 2005) or FindPage with title or text search