The Essence of Software: Why Concepts Matter for Great Design

by Daniel Jackson

Wheeler said “There is no problem in computer science that cannot be solved by introducing another level of indirection.” The style concept achieves its effect—allowing multiple elements to have their format updated at once—by associating formats not directly with elements, but indirectly, through styles. In an email exchange that I had with Wheeler in 2001, he confirmed that he was the author of this adage, but noted that he usually followed it by something like “and this usually reveals new problems.”

“Compatibility means deliberately repeating other people’s mistakes.”)

How concepts differ from features. A “feature” is an increment of functionality. A family of products may be described by a set of possible features, with each member of the family characterized by those features it possesses. Sometimes the term is used for a large aggregation of functions (as in the “photo cataloging feature” of Adobe Lightroom), but it may also represent something smaller (as in the “automatic page numbering feature” of Microsoft Word).

The term “feature” is used somewhat differently in the context of telecommunications to refer to the variety of services—automatic callback, call forwarding, call waiting, and so on—offered by a system that can be sold as distinct products to customers, and configured for them individually. These features, unlike Batory’s features, are very much user-facing, and are implemented not as code transformations but as separate modules.

Requirements engineering has placed less emphasis on the experiences of individual users, recognizing that in many systems, the key requirements may be associated with “stakeholders” who are not always users themselves. Indeed, in many such systems, users and operators are best treated as components of the designed system that fulfill requirements in collaboration with software and hardware. The requirements of a traffic light system, for example, are to achieve safe and efficient flow of traffic, and the individual drivers are relevant only to the extent that the design must account for their behavior in ensuring that the requirements are met.

Beneficent difficulty. Michael Jackson coined the term beneficent difficulty to capture his insight that design methods that make things too easy are suspect [69]. Encountering difficulties can be a positive sign that you are really engaging with the problem and making progress.

In other cases, however, an effective design may require teaching the user to perform an action that may seem unintuitive at first. In some early car radios, to assign a radio station to a preset button, you had to follow a series of steps. In the better designed devices, instructions appeared on the LCD display, seemingly shrinking the Gulfs of Execution and Evaluation. But the design was actually terrible, because it was so inconvenient and tedious to modify the presets, and, worse, one was tempted to do it while driving. A much better solution emerged. To assign the currently playing station to a preset, you simply hold down the desired preset button until it beeps—hardly an action that comes naturally.

This is an essential property of concept composition. It’s what makes concepts comprehensible: a concept behaves the same way, irrespective of context. When concepts are not properly composed, or are adapted to work together in a way that undermines their individual specifications, we have a violation of concept integrity,

Teabox, synergy and an amusing misfit. Teabox is a wonderful company that sells Indian teas directly to customers overseas. Their web app employed the synergistic composition I’ve described, in which free samples are added to the shopping cart as items with zero cost. This led to a funny anomaly. One time I was purchasing some of my favorite teas, and I entered a coupon code that Teabox had sent me previously. It did not give the discount that I expected. I eventually figured out what was going on. The coupon concept used a clever rule that didn’t just apply a percentage discount, but rather applied it to a maximum of three items in the shopping cart—and not just any three, but the three with the lowest prices. Two of these items, it turned out, were free samples. The remedy was to remove the free samples from the cart, after which the total cart price dropped precipitously, since two additional and much more expensive items were now being discounted. This is a nice example of a misfit (Chapter 5) in which a concept itself—in this case, the coupon concept—is perfectly plausible, but placed in an unanticipated context has undesirable behaviors.

This suggests to me that new programming idioms are needed in which concepts are supported in a more direct and modular fashion in the code. It’s not just about dependencies, but also about how the code is organized. Note that in the first object-oriented idiom that I suggested—the naive one that every novice would use, in which Post has an addComment method—the implementation of the comment concept is unfortunately split across classes, since the Post class includes the mapping between posts and comments, a structure that belongs to the comment concept and not to the post concept. A code structure more faithful to the concept design would instead isolate each concept within its own module.

DDD Made Functional!

That example illustrates a problematic interaction when the user makes a mistake (albeit one that is very easy to make). My second example arises in the context of a task that I often want to perform, and for which, due to this design, I needed to invent a workaround. In Lightroom, you can attach keywords to your images. I do this to identify people in pictures. A common task I want to perform is to check a particular keyword, or perhaps replace it by another one. So let’s suppose I key-worded images of my daughter with the keyword “Rebecca” but I want to replace it by the keyword “Becca.” So I filter for images carrying the first (old) keyword; to these, I then add the second (new) keyword in bulk. So far so good. Then I remove the old keyword, and all the images disappear, because they no longer carry the keyword of the filter. This is a serious problem, because I want to complete the task by saving the keyword edits in all these photos to their files on disk. Now, without the photos selected, I cannot execute the save command. (The workaround, incidentally, is to first filter the photos on the required keyword; then to select all; then to turn off the filter, revealing a larger collection in which the relevant photos are still selected. Now they can be edited in bulk without any disappearing as their keywords are changed.) Following Apple’s design of marking the items in the original filtering with their properties would not work here, since the filtering is more sophis...

Another example of overloading in social settings is provided by Kieran Egan whose pedagogical theory [37] starts from the observation that the three conventional purposes of education—socializing students to prevailing norms, teaching them to seek higher truths and transcend prejudices, and helping them fulfill their own personal potential—are fundamentally incompatible. Egan insinuates, more generally, that the success of any social institution may rest on the degree to which its purposes are aligned. Prisons, for example, are problematic because their purposes—punishment and rehabilitation—are in direct opposition, and achieving one can only come at the expense of the other.

Computer scientists who have encountered Alexander only secondhand through the literature on design patterns in software may be surprised to discover, on reading Alexander’s work, that he writes not so much as a designer, let alone as an engineer, but more as a poet, reveling in the spirituality of good design (especially in his latest books [6]). The spiritual and aesthetic components of concept design have yet to be explored, but may be essential if we want to go beyond software that works to software that delights and inspires.

Perhaps this whole discussion seems nitpicky. But while any one small complexity like this might not matter, the accumulation of many such needless complexities exacts a heavy price, from programmer and user alike.

These decision points are thus a symptom of a bad design. In a good design, the design decisions seem to be inevitable. Only one of the options is plausible, and if more than one is plausible, the choice is resolved by following a general rule or sensibility that applies uniformly to all decisions within the product. The user will be able to predict which behavior is most likely at any point, either because only one makes sense, or because the user will be aware (perhaps only subconsciously) of, and guided by, the general rules and sensibilities that have been conveyed by the design and the detailed behaviors the user has encountered so far.

an affordance problem: the preset names don’t signify that they have a clicking affordance distinct from toggling the checkbox.