In computer programming and software engineering, software brittleness is the increased likelihood that software, that previously appeared reliable, now fails (breaks) when presented with new and unusual data that is altered in some way which generates an undiscovered logic error or semantic error not found during initial software testing. The phrase is derived from analogies to brittleness in metalworking. Because of the variety of complex systems such as analog electronics, digital electronics, instrumentation, robotics, software design, heuristics , AI, and more, the general definition that any complex system that cannot maintain control due to a small change within the expected range of operation would be considered fragile, breakable, and thus “brittle”. Any complex system pushed beyond its designed limits of control would likely not be considered brittle.
Causes As software grows larger in scope and users without any maintenance or refactoring, over time the software becomes a legacy system, brittle and unable to be easily maintained without fracturing the entire system. Brittleness in software could be caused by underdeveloped algorithms that might have worked well for their full range of input data at its creation but promptly breaks when confronted with new data that was expected to be within the capability of the algorithm to perform correctly. Following, are some examples:
A good example is an algorithm with an improper error catch that allows a divide by zero to occur, or a curve-fitting equation that is used to extrapolate beyond the data that it was fitted to. Another cause of brittleness is the use of data structures that restrict values. This was commonly seen in the late 1990s as people realized that their software only had room for a 2 digit year entry; this led to the sudden updating of tremendous quantities of brittle software before the year 2000. Another more commonly encountered form of brittleness is in graphical user interfaces that make invalid assumptions. For example, a user may be running on a low resolution display, may witness the software opening a window too large to fit the display. The opposite could be the case as well; say, a window too small for the display, without the capability to resize, or a window, where elements do not fit correctly, because the developers' assumption about the resolution were no longer true. Another common problem is expressed when a user uses a color scheme other than the default, causing text to be rendered in the same color as the background, or a user uses a font other than the default, which won't fit in the allowed space and cuts off instructions and labels. Old codebases may be designed around flawed assumptions or deprecated technologies; sometimes they are abandoned in favor of rewriting a new codebase from scratch. This can free a project of a legacy system's burdens, but it can also be an expensive and time-consuming process. Some examples and reasons behind software brittleness:
Users expect a relatively constant user interface. Once a feature has been implemented and exposed to the users, it is very difficult to convince them to accept major changes to that feature, even if the feature was not well designed 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 continue to refer to obsolete manuals. The original implementers, who knew all intricate details of the software, have moved on and left insufficient documentation of said intricate details. Many such details were only passed onto others via oral traditions of the design team, many of which are eventually irretrievably lost, although some can be rediscovered through the diligent (and expensive) application of software archaeology. 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. If not detected by regression testing, these subtle failures make subsequent changes to the system more difficult. More subtle forms of brittleness commonly occur in artificial intelligence systems. These systems often rely on significant assumptions about their input data and then algorithms and heuristics , believed to correctly process this data, are created. However, when these assumptions aren't met or later found to be even flawed, then these systems containing incomplete algorithms will eventually respond (break) in unpredictable ways when confronted with untested inputs. Systems can also be brittle if the component dependencies are too rigid. One example of this is seen in the difficulties transitioning to new versions of dependencies. When one component expects another to output only a given range of values, and that range changes, then it can cause errors to ripple through the system, either during building (compiling) or at runtime. Fewer technical resources are available to support changes when a system is in maintenance, rather than during development (in terms of the Systems Development Life Cycle (SDLC)).
See also Brittle system Software entropy Software rot Robustness (computer science) Technical debt
References
Robert E. Filman; Tzilla Elrad; Siobhán Clarke; Mehmet Aksit (2004). Aspect-Oriented Dependency Management. Addison Wesley Professional. ISBN 0-321-21976-7.{{cite book}}: CS1 maint: deprecated archival service (link) Virginia Postrel (1999). "Power fantasies: the strange appeal of the Y2K bug – Year 2000 transition problem". Reason. 30 (11). Archived from the original on 2005-09-10. Retrieved 2008-07-25.
