The sum of the parts is greater than the whole

7.7 The sum of the parts is greater than the whole

The venerable claw hammer has been a part of the carpenter's trade for about as long as we have had nails. Used for both driving nails and pulling them, it combines two utility functions on a single wooden handle. Some claw hammers may have improved handles or tempered steel claws, but the basic idea is still the same. The idea has stood the test of time.

Or has it?

Most professional carpenters still use claw hammers today, but the hammer's turf is being challenged by new technologies. The hammer is no longer the best tool for the job, only a convenient substitute. For instance, nail guns have outpaced its ability to drive nails. They do the job much faster with greater accuracy. Nail guns enable workers to construct houses in a fraction of the time needed in the past. The hammer's claw end, however, remains secure. It appears that there is little that high tech can do for the universal wrecking bar.

Some people's software resembles the hammer. It provides a convenient conglomeration of functions that mate well to complete a task. The problem is, many integrated applications like these exist as large, monolithic programs. Sure, they get the job done, but they overwhelm the user-and the system-by incorporating features that may never be understood, let alone used, by the average user.

The Unix approach to building integrated applications is to construct them out of a collection of small components. This way you load and use only the functions you need. You also retain the flexibility to modify selected portions of the application without requiring the replacement of the entire application. Consider Figure 7.1:

Figure 7.1

Both Applications A and B contain the same functions. In this respect, they are equivalent. They work equally well in situations where all four functions are required. Whereas Application B is a large singular program, Application A is a collection of smaller programs, each of which provides part of Application B's functions.

As long as you use all four application functions, there is little difference between the two. Let's suppose, however, that you wanted a new application that required only functions one and two. With Application B, you're stuck with all of B's overhead, even if you're only using half of its functions. Application A, on the other hand, makes it easy to build the new application since you need only "glue" portions one and two together.

Now let us suppose that you wanted an application that contained functions two, three, and five. Application A again makes it easy: You create a module having function five and discard functions one and four. Application B involves a more complex situation that requires the software developer to perform "surgery" on Application B. This shouldn't be a problem, but monolithic programs usually don't lend themselves to easy modification. When a programmer builds a large, integrated application, he or she often compromises future expandability for the sake of higher performance. These compromises generally result in complex code that guarantees a steady source of migraines for the poor person who must make the modification.

Note, too, that Application B doesn't allow the use of pipes between its functions, while Application A probably relies heavily on them. This eliminates the necessity of having to relink the entire application whenever one function changes. It also speeds up development and testing, since programmers who maintain Application A can work on smaller components that are much easier to manage.

One less obvious advantage of Application A is that it facilitates working in parallel by several developers. When programmers know that they are dealing with separate programs that must communicate with each other, they will place considerable emphasis on getting the interfaces between the modules right. This helps to eliminate lots of "spaghetti code."

You may be wondering how the user interacts with the components of Application A. One solution is for Application A to incorporate a separate user interface module. Since Application A's modules are designed to be interchangeable, it would then be possible to adapt the application for different kinds of users by changing its user interface module. The X Window System is a practical example of this. It enables the user to select a user interface from a wide range of choices in a what-you-want-is-what-you-get fashion.