Previous Section  < Free Open Study >  Next Section

1.2 Accidental Versus Essential Complexity à la Frederick Brooks

Frederick Brooks published a very interesting article in the October 1987 issue of IEEE Computer, titled "Conceptual Essence of Software Engineering or There Is No Silver Bullet" [1]. Frederick Brooks is the author of The Mythical Man-Month [2], a must-read text concerning his experiences managing software development projects, including a two-year stint as project manager of the IBM360 project. In his text he discusses what went right in his projects, what went wrong, and why. Anyone involved with producing software, particularly managers, should consider this text required reading. The "No Silver Bullet" article is a follow-up on his insights for software engineering. In it he discusses why we have a software crisis, why there is no magic methodology that will cure all of our problems, and what promising techniques we can use in the future to lessen the crisis.

A fundamental point the article makes is that there are two types of complexity feeding the software crisis; accidental complexity and essential complexity. Accidental complexity occurs due to a mismatch of paradigms, methodologies, and/or tools in our application. This type of complexity can be eliminated given sufficient resources to build or buy tools that complement one another. Object-oriented programming helps to eliminate accidental complexity by providing a consistent paradigm for software development that encompasses analysis, design, and implementation. This is not to say that object-oriented software projects do not contain accidental complexity. The MIS (management information science) world and other domains are faced with a particular type of accidental complexity. These groups have invested large sums of money in relational database technology and are now moving from the action-oriented to the object-oriented paradigm. Relational database schema languages are not expressive enough to describe in a direct manner the complex relationships between data and behavior in the object-oriented world. The result is that object-oriented designers need to translate these complex relationships down to the simplistic relationships found in relational databases. This translation creates accidental complexity, which most MIS companies are willing to live with considering the alternative of purchasing object-oriented databases that are not nearly as thoroughly tested as their relational counterparts. Even in these cases, the object-oriented paradigm allows for the control of this complexity through the use of wrappers, which are abstractional layers that isolate the piece of the application with accidental complexity from the rest of the application. We will talk more about the wrapper mechanism in Chapter 9, which covers physical design issues of the object-oriented paradigm.

The real culprit of the software crisis is essential complexity. Essential complexity revolves around the fact that software is intrinsically complex, and no methodology or tool is going to eliminate this complexity. There are several reasons why software possesses essential complexity:

  1. Software applications, for their size, are the most complex entities that humans build.

  2. Software is intangible and, for the most part, invisible.

  3. Software does not wear out in the traditional sense of machinery with moving parts wearing out. However, software is constantly being used in ways its authors never expected (often uncovering errors), and end users are constantly demanding extensions to their software.

    Previous Section  < Free Open Study >  Next Section