Dijkstra And Refrigerators

I used to read lots of EwDijkstra papers. I was and still am a fan of his. One of the things of his I eventually got around to placing into a tighter context was his constant admonition (pardon the paraphrase) "The essence is simple. Focus on the essence and the system design will be simple, elegant and sufficient."

That is not wrong, per se, but it has a context of applicability. Once the system touches human beings, it stops being simple. People want many things, usually all at once, and many people want many, many things. Even if the heart of the system is simple and elegant, it cannot stay simple as it meets the desires of more and more people.

Consider as simple a device as a refrigerator. It used to be a little box with one room and some coolant running overhead. That is the simple core. Now go to the store: you would like a freezer on top or on bottom? Opening to the left or the right? How about split down the middle, freezer to the left (or right)? Big shelves up top, wide or narrow door, split or full shelves? Ice cube maker inside? In the door? Whole or crushed ice? Iced water as well? ... and we haven't even started on the colors or trim.

That is just a refrigerator. Look at a car, read the sticker options. Imagine what it must be like trying to design and price all those variations! Imagine a payroll system for unions, white collar workers, and executives, each wanting to be preferred. How many anomalies can you think of?

The core of the car, the refrigerator and the software can be simple - as Dijkstra reminds us. Once it touches the outside world, it becomes inherently complicated. Bumpy, I sometimes say, "People are all bumpy; they don't abstract well down to a circle with two eyes. Much of the active part of the people is in the bumpiness."

The core is what XP is after with their SpikeSolution, I suspect. -- AlistairCockburn

In a spike, one ignores the whole so as to get at the core of a part, a shock absorber, for example. It is only the first step in getting a shock absorber to work well in a car. -- WardCunningham

Note that typical refrigerators actually can be reconfigured between opening on left side or the right side by the (sufficiently technical) user; this is not a compile-time or design-time option, and adds relatively little complexity to the design in itself. -- SamuelBronson?

The additional complexity you're attributing isn't what Dijkstra is calling the essence. The essence for a refrigerator is still a little box with some coolant. The essence of a car is still a chassis, an engine, and controls. The other stuff is all just decorations; additions added to make it more palatable to humans. Dijkstra is saying that for the system design, focus first on the core. The decorations will be added later as you make it fit for human consumption. Even a complex, "bumpy" system is core plus decorations.

I think y'all are just talking on two different levels of abstraction. Dijkstra is looking at the core; you are looking at the full, complete system. -- RonRomero

What you've called decorations, in contradistinction to essence, is roughly what MrAristotle referred to as "accidents". This debate is not new ...

See also SoftwarePlatonism

Those levels of abstraction are a real bear though. One thing that incremental development and refactoring can give us - if we work at it - is a way to continually discover and separate abstractions that have gotten tangled together in the code. I think that these "essential" abstractions are analogous to AlexandrianCenters. It can seem as if there is one center/abstraction/essence with a bunch of details hanging off of it. But in reality there are many centers. Nothing that is worth having in a product is an isolated detail. Each of these details is part of some essence. Noticing the details, recognizing their essential centers, and juxtaposing those centers with each other in an aesthetically coherent and pleasing way is at the heart of writing good software just as it is the heart of good architecture. -- PhilGoodwin

Regarding the distinction between core and decorations (between essence and accident), I see that distinction being lost on many software projects, and that causes a lot of needless problems (in Brooks' terms, non-essential complextity, accidental complexity). A solution to that is to always be sure that the core/essence runs without any of the decorations/accidents. This is really nothng more than MVC, where the core is the model, and the accidents are the views and controllers. But by always continuously testing that the model loads and runs without the views and controllers, we've able to detect when we pollute the core/essence/model. --John