To the economic question "Why is software so expensive?" the equally economic answer could be "Because it is tried with cheap labour.". Why is it tried that way? Because its intrinsic difficulties are widely and grossly underestimated. So let us concentrate on "Why is software design so difficult?" One of the morals of my answer will be that with inadequately educated personnel it will be impossible; with adequately educated software designers it might be possible, but will certainly remain difficult.

"Why Is Software So Expensive?" An explanation to the Hardware Designer, Selected Writings on Computing: A Personal Perspective, Edsger W. Dijkstra, Springer-Verlag, 1982

Computers are becoming a pervasive part of our lives. Many of us use computers at work. When we drive home, we are driving in an automobile that contains several computers. In a few years the digital televisions we watch will be controlled by a powerful computer. When we get up in the morning we might even make our toast in the mythical computerized network toaster (running Jini on the same network as the network espresso maker). Each of these computerized devices contains software. In the cases of the computers controlling anti-lock breaks in an automobile the software is, fortunately, small and simple. However, modern operating systems like Windows NT, which reportedly consists of many millions of lines of source code, are very large complex systems.

The cost of developing and maintaining software remains high and software is much less reliable than it should be. Anyone who has used computers long enough has a horror story to relate regarding buggy software. In my case it was an Attachmate dial-up program that trashed by Windows NT boot sector, forcing me to spend all of Memorial Day weekend reinstalling my software.

When I speak about computer programming as an art, I am thinking primarily of it as an art form, in an aesthetic sense. The chief goal of my work as an educator and author is to help people learn how to write beautiful programs.

Computer Programming as an Art, Donald E. Knuth, ACM Turing Award Lecture, 1994, reprinted in Literate Programming by Donald E. Knuth, 1992

The high cost of software has provided a powerful business incentive to reduce its cost. If software development can be reduced to an engineering methodology, then it might be possible to produce software in something similar to a factory setting. This would reduce the cost and improve the quality of the produce. The idea that software is created by skilled artisans runs counter to this theme.

Since the 1960s the software engineering community has been trying to develop techniques that would make software development less expensive and more reliable. These techniques range from structured programming, which became popular in 1970s, to modular design, which became popular in the 1980s, to object oriented programming, which became popular in the 1990s, and remains a popular design methodology (if we define methodology broadly).

There has been some progress in software engineering. Programming practice has improved. Programming languages are more powerful and capable of expressing abstraction better. At least on the Windows platform there have been significant improvements in the development environments. Powerful computer systems allow us to trade some amount of program efficiency for abstraction. These factors have improved programmer productivity slowly. This is fortunate, since we are also designing software systems which are far larger than they were ten years ago.

As each programming methodology has been proposed there have been those who have claimed that it would be the silver bullet that would allow high quality software to be created by programmers without years of experience (e.g., inexpensive labor). This continuing cycle of fads in the software community provide rich opportunity for consultants who claim that they can come in and save corporate software organizations if only they will follow the course put forward by the consultant. But each time the proposed silver bullets have proven to be illusion. At the time this review was written the current fads include the Universal Modeling Language (UML), Extreme Programming and Design Patterns.

Some fads (Extreme Programming, for example) are silly and could only be proposed by consultants with no responsibility for product delivery and believed by management with no experience developing software. But other fads have real value at their core, accounting for their wide spread popularity. Object oriented languages like C++ and Java, in the hands of a careful user, do result in better software. Design patterns provide a useful way to describe and view software.

The book Design Patterns by Gamma, Helm, Johnson and Vlissides (on occasion referred to as "The Gang of Four") launched the "design patterns" fad. The observation made by the authors is that software applications and application components follow certain design patterns. These range from simple patterns like iterator and visitor patterns, which iterate or traverse over a data structure, to complex design patterns like an interpreter which processes a language.

The authors of Design Patterns classify the software patterns they discuss in three categories:

1. Creational Patterns
2. Strucural Patterns
3. Behavioral Patterns

The class of pattern is discussed along with specific examples which are outlined using C++ examples in most cases. The design of a graphical document editor named "Lexi" is a central theme that runs throughout the book. The authors show how a number of design patterns fit into the design of this larger piece of software.

Design Patterns is well written and the examples are generally clear. I found the book enjoyable to read and in several cases it got me to think about the software I was writing in a different way. Many of the patterns, like the factory pattern which creates objects are pervasive. For example, the ANTLR based Java parser for the BPI Java Compiler uses factory classes to allocate abstract syntax tree (AST) nodes and objects to represent constants. Another factory class is used to allocate local symbol tables.

In the preface the authors write:

A word of warning and encouragement: Don't worry if you don't understand this book completely on the first reading. We didn't understand it all on the first writing! Remember that this isn't a book to be read once and put on a shelf. We hope you'll find yourself referring to it again and again for design insights and for inspiration.

This comment is true in that a number of the issues discussed in Design Patterns require a lot of thought and are issues that a programmer struggles with throughout their career. Many of the design patterns discussed in this book are used in the creation of reusable class libraries, which take a great deal of insight and experience to build so that reuse is more than just a name. But I found nothing in design patterns that justifies the author's claim

Once you understand design patterns and have had the "Aha!" (and not just a "Huh?") experience with them, you won't ever think about object-oriented design in the same way. You'll have insights that can make your own designs more flexible, modular, reusable and understandable

The implication here is that design patterns are a sort of transformational understanding. I certainly did not find this the case. Design Patterns is a good book. It is worth spending money and time on. As the authors suggest, it is a book that is worth rereading. But it is nothing but a faddish idea that design patterns are some kind of quantum leap in software understanding. Unfortunately that process is a career long challenge. There are only steps along the way and there is no arrival at a final destination.

Ian Kaplan - 5/2000

Book review table of contents

back to home page