A Story of Four Benches

Hi, my name is Shane Clifford, and I am a developer here at Intentional Software Corporation. The following story is inspired by the work we are doing at Intentional, as well as an experience related by Christopher Alexander in Book 3 of The Nature of Order, at the end of Chapter 11.


Once upon a time, there was a village with four neighborhoods. Each neighborhood had a little park that its inhabitants enjoyed, and there was a bit of competition amongst the neighborhoods to have the best park in the village.

One day, during a neighborhood meeting, one of the neighborhoods decided to add a new bench to their park. Before the next meeting, the head of the neighborhood association sent requests to three world-famous bench manufacturers requesting proposals based on their latest designs. At the next neighborhood meeting the three designs, which were the height of fashion in manufactured benches, were presented to the members of the neighborhood. After some consideration and debate, it was put to a vote, and one of the benches was selected with 45% of the vote. Many of the neighbors were unhappy with the selection, but clearly the most popular bench had prevailed through this democratic process. They now had the best park in the village!

Well, one of the other neighborhoods observed what had happened, and they thought, “Surely, we could do a better job of getting a bench we are all happy with, and then we will have the best park in the village!” The head of their neighborhood association found a different bench manufacturer that offered mix-and-match bench components, so you could order a “customized” bench to meet your specifications. The neighbors began to select their favorite components from the various pages of the catalog, but soon discovered that the wood seat slats that they liked did not come in the
right length, and the back with the pretty scrollwork did not work with the green legs they liked most. Eventually, they chose some metal slats and different legs; because most people thought
they would have the best bench if it had the pretty scrollwork. The bench was installed and the neighbors were very proud of it (but they didn’t sit on it very often.)

A third neighborhood observed what had happened in the first two neighborhoods. At their next meeting, one of the neighbors said, “I bet we could have the best bench in the village if we built it ourselves! Surely, we can do at least as well as the other neighborhoods did, and we can do other things with the money we save.” Everyone thought this was a wonderful idea. A team was put together and—even though no one in the neighborhood had ever built a bench before—they set out collecting the raw materials and putting it together. Occasionally, the team went back to the entire neighborhood to get suggestions on paint color or the height of the back. Eventually, they unveiled a simple, but very beautiful bench in their park, and all of the neighbors were very proud. Their hand-crafted bench was clearly superior to the other two benches. (If you ignored the fact that it wobbled a bit when you sat on it, and didn’t think about the spot on the back where some mistakes had been patched up during construction.)

Now the fourth neighborhood was very unsure about what to do. They did not feel comfortable building their own hand-crafted bench, but also wanted something much better than either the manufactured bench or the mix and match, manufactured component bench they had seen in the other neighborhoods. Finally, at their next meeting, one of the neighbors said, “I saw an ad in the newspaper for a new company that is offering a new bench making experience.” The neighbors were very tentative, and skeptical, but decided it was worth taking a chance in order to outdo the other neighborhoods and also to keep their park a beautiful and special place. They contacted the new bench maker and he asked to attend their next neighborhood meeting.

When he arrived, he had a flat-bed truck with several machines in the back. The bench maker took the floor and immediately began asking questions. “What is the most important feature of this bench for your neighborhood?” Eventually, the neighbors agreed that it needed to be comfortable. “Ok, what is the next most important feature of this bench?” After a lot of discussion, they decided what was really important was that it face toward the most beautiful view in the park.

These questions went on for a while, and soon, the bench maker began arranging his machines in the back of the truck into a new sequence after each question; later, after each question was answered, he turned knobs or adjusted levers on individual machines. Many of these later questions covered somewhat more detailed subjects such as material, shape, color, and height. After about 20 questions, an image of their bench, positioned where they had decided was best, appeared on a large screen on one of the machines. The image changed as each subsequent question was answered. Sometimes, their answers changed after seeing the latest image, and they would backtrack a bit.

Eventually, they discussed much smaller, ornamental details of the bench. Finally, after a few hours, the 50th question was asked, “What should the shape of the feet be on this bench?” After some discussion with the bench maker and going over several options he presented, the neighbors agreed a particular claw foot complemented everything they had decided up to that point. The bench maker thanked them all for their help, and pushed a button at one end of his series of machines.

The machines hummed for a short while and eventually a beautiful bench that matched the one in the image emerged from the machines. The neighbors installed the bench in the exact place they had selected. They all felt very proud to have taken part in making their bench, and enjoyed visiting the park much more from that day forward.

How is this story relevant?

Christopher Alexander’s A Pattern Language provided well known inspiration for the concept of patterns now widely taken for granted in the software industry. Alexander’s patterns of course were specific to architecture and construction of buildings, but the parallels to software development are easily drawn.

In The Nature of Order, Alexander describes a new fundamental process for architecture and construction that has already inspired new work in software. A good example is Organizational Patterns of Agile Software Development by Jim Coplien and Neil Harrison.

Alexander’s fundamental process is generative, iterative, and transformative. It adheres to a tenet that the owner of a building must be involved in all phases of its design and construction. The same applies to the architect. This does not mean the owner and architect do all of the work. It simply means that they are aware of what is taking place, and are making the major decisions. In his fundamental process, the design of a building neither begins nor ends with drawings. Planning, design, and construction must be intimately intertwined in order to implement a generative approach. This combined activity is called making. Alexander acknowledges that this will also require "ultra-high-tech” materials and equipment and advancements in construction techniques in order to be cost-effective in today’s environment.

In this definition of making, it is theoretically impossible for a successful building to be built from a set of drawings which specify every detail, because that would cripple the capacity of feedback to help shape the elements and details as they are built. […] our 21st-century techniques allow details to be fitted exactly to their positions in the whole through some new form of almost “biological” process.

–Christopher Alexander, “All Building as Making.” The Nature of Order, Book Three: A Vision of a Living World. Berkeley: CES, 2002.

I see many similarities between Alexander’s fundamental process and the fundamental process Intentional Software enables. When making Intentional Software, the domain experts’ intent is captured in the system in their own domain terminology. The programmers contribute their own expertise both to enhance the expressive power available to the domain experts and to generate an executable system. The software is made through the combined effort and knowledge of domain experts and programmers working on the structured code.

In many ways, we software developers should be better off than building owners and architects. Making software, by its nature, is more readily adaptable to a fundamental process of this sort than is making physical things like buildings. Unfortunately, the software community has not had the technology or process necessary to take advantage of that fact.