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 50^th 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 21^st-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.

Comments

[Peter Halas(z)]

Thanks for pointing out the relevance of Professor Alexander’s work. The following is from:
http://www.natureoforder.com/library/reply-to-saunders.htm

THE NATURE OF ORDER - SOME SOBER REFLECTIONS
ON THE NATURE OF ARCHITECTURE IN OUR TIME

Professor Alexander wrote this, as part of his reply to a Commentary, written by William Saunders, and published by Architectural Record in the May issue 2002.

“ . . . the idea of wholeness. In the last two decades, physicists and other scientists and philosophers of science have begun to discover that a wholeness-based view of the world is, essential to proper understanding . . . A view of wholeness as an existing, guiding structure is essential in quantum physics; essential in biology; essential in ecology; in one form or another, essential in almost every branch of modern science.

Yet even in these rather precise fields, it has been difficult to forge a scientifically precise concept of wholeness. The idea places demands on science which stretch the very notions of scientific inquiry . . . ”

What does this mean to us, as software practitioners? I believe that the greatest detractor from what FP Brooks, in his book The Mythical Man Month called the “concept of the Cathedral” is complexity.

Just as there is something in the physical world called the “latent heat of fusion” before ice can turn into water, and “latent heat of evaporation” so water can turn into steam . . . there is, for software efforts . . . for EACH level of abstraction, a latent “simplicity” of implementation success (or the corollary . . . latent “complexity” of implementation failure).

EXTRA “governance” efforts and add-on initiatives have to be taken into account to reduce the 50% failure rates being currently observed.

• “Simplicity” implies . . .

having adequate user training, process alignment, management involvement and vision, usability peer reviews, a lack of “time line pressures”, process maturity, use of tools, use of employee incentives (carrots / sticks), and as needed . . . clear audit trails to demonstrate the meeting of regulatory requirements. The fostering of simplicity (ie: unfussiness) also results in the presence of such “quality” factors as: good performance, rich functional features, reliability, and as needed . . . the system is maintainable / serviceable, has a decent user interface (Aesthetics), and user satisfaction metrics indicate that they feel they have received Quality and Value

• “Complexity” implies . . . .

• at the project and enterprise level:

lack of management involvement, lack of vision, lack of Trust, lots of Anxiety, confusion, lack of “focus”, infrastructure incompatibilities, resistance to change, frustration, cynicism, stress, no use of peer reviews or walkthroughs, and a stress on artificial deadlines.

• at the code level:

convoluted logic, too many levels (of inheritance – for example), data binding - FORTRAN Common issues, reentrancy / multi threading issues, memory management exposures, not adequately taking into account such process and workflow issues as two-phase commits, etc.

[Phil Bachmann]

I am excited by the idea of bench factories though some questions naturally arise:
- What if the machines' makers haven't anticipated every customer requirement?
- How long will it take a machine operator to learn how to use these many knobs and levers proficiently versus screwdriver, saw and lathe?
- What if the machines don't work together quite right?
- What if a machine fails on a certain combination of settings? How long will it take for the engineers at the factory to fix it? What if they don't want to fix it?

I have my own answers to these questions and since you're testing your software with real-world customers I guess you guys do too.

[Amiruddin Nagri]

Hi,

Nice article about the methodology intentional software uses, but isnt it the same as Agile Software Development as I read in articles, gathering user requirements, capturing the core requirements, iterative development etc.

so whats the difference between both of them ???