This is the first section of a two-part story. The second portion will appear in the April 29 edition of Computergram International.
Some ivory-tower advocates of patterns are too busy playing Plato. It’s time boilerplate design was thrown to the people, Lloyd Blythen believes
Weighing heavily on my conscience is a lie I once told some gullible college kids: that programming is a matter of simple principles. As the 600-odd pages of Donald Knuth’s Fundamental Algorithms attest, there’s nothing fundamental about programming at all.
If only we could distill the years of experience that truly expert programmers draw on in breaking down a task and performing it. Then, instead of a bottom-up attack – one that bewilders the student with algorithms, data structures and class-hierarchy designs before they’re able to cement their knowledge by using it – we could start by learning essential, ubiquitous techniques for software design, which we’re sure to repeat over and over, and start applying them from the outset. I don’t suggest that the minutiae are avoidable; they’re not. But as an example, instead of learning five sorting algorithms it might be beneficial if we learned to recognize ‘sort-worthy’ applications first. Most programmers use few sort routines, and without knowing more than one it’s possible to learn a lot about software design.
It’s been done, and I hasten to add that it wasn’t my idea. In fact, it wasn’t even a programmer’s idea to start with. Just as chaos theory found its way into mathematics by courtesy of an atmospherics scientist, so-called ‘patterns’ were co-opted by the software community from outside. (Patterns amount to one of the biggest applications of re-use that our industry’s ever benefited from.) For decades Christopher Alexander, an architect (the kind who talks bricks, not bytes), developed a unique scheme for planning towns and buildings. He identified dozens of time- honored, fundamental design solutions that applied across many scales and in many situations, along with the ‘Alexander form’ for describing them. His idea was that the best of skilled design should be available as a set of boilerplate abstractions.
Take, for example, the problem of negotiating a dip. One high- level pattern for solving it involves a bridge of some sort – without regard for how the bridge is best constructed in a given situation, or for whether the dip amounts to a dry gulch, a street below two neighboring skyscrapers, or a river flowing between two banks, or for whether the bridge is to be traversed by trains or pedestrians. Other patterns applicable to the same problem might involve tunnels – again, whether for people, ducks or cables is immaterial to the pattern’s usefulness.
Such patterns were most valuable for one feature: they strenuously avoided specifying implementation details, so that their applicability might be as broad as possible. Over time, Alexander indexed several hundred abstractions for solving design problems. By then he was prepared to claim that an entire building might amount to no more than the realization of a set of patterns, many of them applied repeatedly and at varying scales, and sometimes in concert. He’d identified re-usability and genericity in architecture, and set about trying to have them applied deliberately rather than haphazardly. But Alexander was ahead of his time: many in the architectural community interpreted his efforts as an attempt to stifle an art form, and for a while they spurned him as an untouchable.
Content from our partners
It took Kent Beck and Ward Cunningham to recognize that Alexander’s work held the promise of a revolution – not in architecture, but in the software engineering field. The first software design patterns arrived in the form of their recommendations for GUIs and for capturing business models in software, in the early ’90s. In 1991, a set of patterns was published as part of a now-famous doctoral thesis by Erich Gamma. Partly as a result of its being written in German, this work didn’t receive widespread attention.
