From Wikipedia, the free encyclopedia

Software brittleness is the humorous term that describes the increasing difficulty of fixing older software. The term is derived from analogies to metalworking.

When software is new, it is, essentially, infinitely malleable; it can be formed to be whatever is wanted by the implementors. But as the software in a given project grows larger and larger, and develops a larger base of users with long experience with the software, it becomes less and less malleable. Like a metal that has been work hardened, the software becomes a legacy system, brittle and unable to be easily changed without fracturing the entire system.

There are many reasons behind this brittleness:

• Users expect a relatively constant user interface; once a feature has been implemented and exposed to the users, it's very difficult to convince them to accept major changes to that feature, even if the feature was not well designed to begin with or the existence of the feature blocks further progress.
• A great deal of documentation may describe the current behavior and would be expensive to change. In addition, it is essentially impossible to recall all copies of the existing documentation so users are likely to be referring back to obsolete manuals anyway.
• The original implementors (who knew how things really worked) have moved on and left insufficient documentation of the internal workings of the software. Many small implementation details were only understood through the oral traditions of the design team and many of these details eventually are irretrievably lost, although some can be re-discovered through the diligent (and expensive) application of software archeology.
• Patches have probably been issued throughout the years, subtly changing the behavior of the software. In many cases, these patches, while correcting the overt failure for which they were issued, introduce other, more subtle, failures into the system. These subtle failures make subsequent changes to the system far more difficult.

It is common for software systems to become slightly brittle within, say, five years and nearly unmaintainable within fifteen years. It is a rare, very-well-managed software project which can be sustained for a longer time than that. More often, the old code base will simply be abandoned and a brand-new system started from scratch; the new system can be free of many of the burdens of the legacy system.

• Edward Yourdon
• Fred Brooks
• The Mythical Man-Month
• Software rot
• Stovepipe system