9.3 Patterns as Literature

Aside from their technological roots, software patterns emerged out of another movement in the late '80s: literate programming and the notion that documentation and even programs could beand should be written as literature. The concept of literate programming originated with Donald Knuth, and influenced Kent Beck noticeably, from practical considerations:

Traditionally, the programmer's role has been to understand a problem and encode that knowledge in a program a computer can execute. The problem with this approach is that focusing on the computer as the consumer of programs leads to programs that are difficult for other programmers to understand. A literate program is a literary entity, written to be read from beginning to end, and taking on the character of a book or essay. Literate programming expands the role of the programmer to include the responsibility for organizing a program in such a way that a reader is led naturally to an understanding of the decisions that shaped the code. (Beck and Cunningham 1987)

In order to produce literate programs, an appropriate programming language was necessary. None of the familiar ones were suitable. In some ways, patterns could be seen as an available model or even as an alternative.

Christopher Alexander's patterns are self-conscious literature. He uses an essay-like form for structuring patterns and, in particular, for describing the problems they solve. The simplicity and practicality of these essays, almost stark in their directness, gives his patterns a special power. The quality of his writing again simple, straightforward, and direct gives his patterns a resonance. The best of his patterns provoke strong emotional reactions and urge a creative response in their readers.

For example, a pattern called Dancing in the Street talks about the physical conditions that will encourage people to do just that dance in the streets. He notes that dancing in the street is an "image of supreme joy" in the music and theater of most cultures, and mentions "Balinese dancers who fall into a trance whirling around in the street." But, he laments, it has mainly disappeared in our culture. He suggests that there may be opportunities to reintroduce dancing in the street and says:

[T]he right setting can actualize it and give it roots. The essentials are straightforward: a platform for the musicians, perhaps with a cover; hard surface for dancing, all around the bandstand; places to sit and lean for people who want to watch and rest; provision for some drink and refreshment (some Mexican bandstands have a beautiful way of building tiny stalls into the base of the bandstand, so that people are drawn through the dancers and up to the music for a fruit drink or a beer (Alexander, Ishikawa, and Silverstein 1977, 321)

Ideally, it was felt that software patterns should do the same. And, just as Alexander's more human way of building captured the attention of software developers, literature (including Alexander) offered the promise of a more human way of communicating similar to Koans, Metaphors, and Parables (Coram 1997).

The patterns community has attempted to meet this ideal by treating software patterns as a body of literature, and by treating pattern-writing as a creative exercise to be nurtured the way creative writing is nurtured: through workshops, open publication and discussion, and communal review. This attitude carries through to a respect for the work of individual authors:

As you examine the contents of [PLoP1] carefully you will observe a rich diversity of pattern forms. We made every effort to preserve the authors' original forms. We avoided tampering with individual expression as much as possible: We made no attempt to enforce a uniform writing style. Although the book lacks the voice of a single author, we wouldn't have it any other way. We hope you join us in celebrating this diversity in the formative stage of a new body of literature. (Coplien and Schmidt 1995, ix x)

Along with the literary bent came a focus on reflection, introspection, and experience as a source of knowledge, as opposed to what is perceived as a current obsession with the new:

[The founders of PLoP] had come to realize that the advance of their discipline was limited by a bias in its literature a product of the traditions of scientific publication to favor the new, the recent invention or discovery, over the ordinary, no matter how useful. The founders' interest in the ordinary may have come from their observations that projects fail despite the latest technology for lack of ordinary solutions. [They all] agreed to focus their attention on the dissemination of solutions. (Johnson and Cunningham 1995, ix-x)

However, although the idea of patterns-as-literature is well served by the practices of the patterns community, the results rarely live up to the ideals. Software developers being software developers and not writers (usually), they are typically more comfortable with the concrete and defined than the elusive and allusive. And so, the opposite side of the coin is apparent in any review of the patterns literature: an abundance of templates and recipes, and very few essays that create the aha reaction, as it's called.

For those pattern writers who have the necessary skills and needs to complement literary ambitions, the results verge on real literature: Jim Coplien and Dick Gabriel come to mind. The following "Simply Understood Code" is an example from Dick Gabriel:

Simply Understood Code

at the lowest levels of a program are chunks of code. These are the places that need to be understood to confidently make changes to a program, and ultimately understanding a program thoroughly requires understanding these chunks.

* * *

In many pieces of code the problem of disorientation is acute. People have no idea what each component of the code is for and they experience considerable mental stress as a result.

Suppose you are writing a chunk of code that is not so complex that it requires extensive documentation or else it is not central enough that the bother of writing such documentation is worth the effort, especially if the code is clear enough on its own. How should you approach writing this code?

People need to stare at code in order to understand it well enough to feel secure making changes to it. Spending time switching from window to window or scrolling up and down to see all the relevant portions of a code fragment takes attention away from understanding the code and gaining confidence to modify it.

People can more readily understand things that they can read in their natural text reading order; for Western culture this is generally left to right, top to bottom.

If code cannot be confidently understood, it will be accidentally broken.

Therefore, arrange the important parts of the code so it fits on one page. Make that code understandable to a person reading it from top to bottom. Do not require the code to be repeatedly scanned in order to understand how data is used and how control moves about.

* * *

This pattern can be achieved by using the following patterns:

LocalVariablesDefinedAndUsedOnOnePage, which tries to keep local variables on one page.
AssignVariablesOnce, which tries to minimize code scanning by having variables changed just once.
LocalVariablesReassignedAboveTheirUses, which tries to make a variable's value apparent before its value is used while scanning from top to bottom.
MakeLoopsApparent, which helps people understand parts of a program that are non-linear while retaining the ability to scan them linearly.
Use FunctionsForLoops, which packages complex loop structure involving several state variables into chunks, each of which can be easily understood. (Coplien 1997)

For the template-oriented (and "practical") pattern writers, whose skills and needs are decidedly technical, the focus on creating a literature can result in what some have called "tedious" verbiage. But both factions have their place in the patterns community.