- Measurable But Variable Forces
- The Harvest Continues
- Incremental Change
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In my experience, codifying such patterns benefits us most by giving us a language to describe designs at a higher level of abstraction. All the interesting patterns I work with tend to transcend single classes or components, thus naming the structure and behavior of a society of such artifacts, often with cross-cutting concerns. Furthermore, prior use has proven that these patterns are useful. This is the premise of Henry Petroski's To Engineer Is Human (St. Martin's Press, 1985), in which he describes the engineering process as one that involves incrementally improving solutions that worked in the past as well as remedying solutions that failed.
If you study the code of Apple's MacPaint and early versions of Adobe's Photoshop, you'll see several architectural similarities. Both have basic abstractions for the drawing surface, surrounded by abstractions representing the tools that manipulate bits cast on that surface. The developers of these early applications assumed that users would create small to modest-sized images. This made sense, given the limits of displays and printers at that time.
As with every innovative product, the presence of such applications changed users' expectations and in turn pushed developments in displays and printers. As Photoshop gained traction in the marketplace (ultimately owning much of that market), users demanded the ability to create modestly larger images (such as posters and 12 x 12 inch scrapbook pages) and then really big images (such as billboards and advertisements on the sides of buses) to truly huge images (NASA's manipulation and combination of photographs to make them planet-sized).
Could Bill Atkinson have designed the first version of MacPaint to accommodate NASA's present needs? Certainly not: computers' pragmatic limits at the time would have worked against even the most innovative solution. Should Bill have designed the first version of MacPaint to be able to manipulate even really big images? Certainly not: it would have been architecturally wrong to optimize MacPaint for use cases that didn't even exist at the time.
I'm trying to conduct my software archeological digs in a detached manner, meaning that that I'm not (initially) passing judgment on each architecture that I uncover. It is what it is, and be it accidental or intentional, it's a legitimate solution to the given problem simply because it exists and because it resolves the forces on that system.
Having completed a few such digs, I've realized something that really shouldn't have surprised me. If you look at each system's earlier incarnations, usually you'll see the same basic architectural pattern, manifest in decreasingly refined forms as you move back in time. Occasionally, you'll find some clear discontinuities in these patterns, primarily caused by the extreme tightening or relaxation of some force. This is as it should be with any good engineering process. At first, when a new problem confronts us, we try many different approaches, but over time, for the same kind of problem, solutions tend to converge to the same, more constrained, solution space. In other words, a solution to a contemporary problem is what it is because it was what it was, with all failed paths having been tossed into the ashbin of history.
Grady Booch is an IBM Fellow and one of the Unified Modeling Language's original authors. He also developed the Booch method of software development, which he presents in Object-Oriented Analysis and Design. He's now working on a handbook of architectural patterns, available at http://www.booch.com/architecture. Contact him at architecture@booch.com.