The Lego Brick Metaphor

Exploration of the metaphor begins with considering what it implies about the development process: that there is a necessary separation between the process required to create objects (Lego bricks) and the process of assembling those objects into useful products (software, in our case). The metaphor suggests that

• Creators are (probably) adults working for the Lego Company.

• Users are children (at least at heart), ages 4 to adult.

• Creators have specific concerns and use specialized processes to accomplish their goals.

• Users care little about the components, as components. Their concerns focus on what can be built with the components and the ability of the artifact to satisfy their needs.

• The component engineers need to be very concerned with the internal structure of the bricks, what kind of plastics will yield the correct degree of malleability, colorfastness, friction to keep them together, spacing of the pips at the top of the brick, and so on. They also have to create components that transcend particular applications because their goal is to build bricks equally useful for dinosaur and spaceship construction. More important, they want bricks that can be used successfully by unknown end users to build whatever it is that they have imagined.

• Users want to move easily from concept to construction without the need to concern themselves with technical details. They want rapid feedback, they want to be able to change their mind in mid-construction, and they want the artifact constructed to operate in their world as it is.

Applied to software, the metaphor suggests separation of domain decomposition and object definition from the tasks of assembling applications and solving specific operational problems. To some degree, with some implementation languages, this separation has started to occur. Consider the class libraries that come with a language such as Smalltalk or Visual Basic. Many of the classes (the collection and magnitude classes, for instance) in such libraries reflect the same kind of general and abstract thinking that leads to good software Legos. Another example of this separation is the attempt to create visual programming environments for application assembly that are at least quasi-independent of the underlying implementation language. Such attempts are but a start toward an object-mature world, where the two tasks are as clearly separated as they are in the world of Legos.

Another, critically important, aspect of the metaphor is the ability of users to successfully employ the bricks based solely on their intuitively obvious external characteristics. A child can look at a brick and instantly tell whether it is suitable for inclusion in the project at hand. It is not necessary to know anything about the chemistry of plastics or whether this particular brick was made at Sun BuildingBlock Corporation or Microsoft BuildingBlock Corporation. There is no need to read a complex user manual that explains either the brick or how to use it. There are, however, patterns: diagrams suggesting proven ways that you can construct a family of similar artifacts ”houses, for example.

Software objects cannot even approximate this degree of composability, but the metaphor suggests that full realization of object potential requires satisfaction of this characteristic.

The fact that two different groups of people, and two different processes, are involved in brick creation and artifact assembly, one group being adults and the other children, might lead one to believe that the metaphor de-skills the task of application assembly ”after all, it can be done by children (or end users, perhaps). This would be a misleading conclusion.

The Legoland store in the Mall of America periodically sponsors two events. (Located in Bloomington, Minnesota, the MOA is the largest shopping mall in the United States.) In the first event, children are invited to use the unlimited set of bricks at hand to construct various things. Prizes are given to the best constructions. The second invites professional architects and designers to use the same bricks to create various structures, which are then sold as part of a charity auction.

As should be expected, there was a large qualitative difference between the constructions of the architects and those of the children. The building bricks remained the same. The architects, however, were able to bring to bear other skills ”proportion, geometry, aesthetics, and so on ”that the children did not yet possess. The architects were domain experts (end users) who were able to use the bricks to build solutions that fully exploited their domain knowledge. They were able to use the Lego bricks to simulate the way they wielded girders and bricks in the real-world domain where they worked.

Two other items suggested by the metaphor are related. Objects should be simple, and there should be relatively few of them. There are fewer than 10 basic Lego brick types. (Kits contain additional parts, each of which is highly specialized, such as tiny human figures and motors, but these cannot be considered true Legos.) There are only 134 elements and only six quanta. The vast majority of houses in this country are built with fewer than 10 standard sizes of dimension lumber. In all of those cases as well, the base elements are simple and highly specialized.

One of the heuristics for object discovery is Find the nouns. Each noun in a domain description is a potential object class. Estimating the minimal class set could involve a simple count of nouns employed in a domain.

Expanding on this heuristic, how many classes would be required to model the universe? Well, how many nouns are required?

The Oxford English Dictionary has about 550,000 words. An English teacher once told me that about 40 to 45 percent of the words in a dictionary will be nouns.

If we eliminate proper nouns and synonyms, that percentage will be reduced to around 25 to 30 percent of the words describing potential objects. Eliminating archaic nouns ”bodkin and amanuensis, for example ”will reduce the percentage still further, to 15 or 20, perhaps. This translates into about 110,000 classes. A pretty large number but clearly finite.

Instead of the OED, however, a better estimate might be obtained using the vocabulary required to read the average daily newspaper. Most things are quite adequately described in a newspaper.

Vocabulary required to read a typical newspaper: about 1400 words!

Using the 30 percent estimate (we don t have archaic terms to eliminate, hopefully) suggests a need for only 420 classes. Allowing liberal ability to add classes representing objects that do not make the paper, we still come up with fewer than a thousand classes to model all typical domains of human interest.

If your problem domain ”or worse , your application ”has thousands of classes (and I have seen some), you probably have yet to master object thinking.