Tuesday, August 28, 2007

What the Maasai Can Teach Us About Software Engineering

An article on the Maasai started me thinking about why I like my teakettle better than the microwave. The teakettle is no easier to use than the microwave; it probably takes slightly more energy; and of course, boiled water is boiled water.

However, when the teakettle whistles when the water boils, that whistling is an integral act that stems from the nature of the process. Certainly, someone had to design the whistle and attach it to the kettle. But once this was done, the whistle noise occurs automatically and naturally arises naturally as a side-effect the primary process for which the kettle was designed (i.e. boiling water).

A microwave oven, by contrast, beeps because of a series of processes disconnected from function being performed and of an arbitrary character. Even in a very advanced microwave oven that can sense the water boiling, the chain of events resulting in the beep is still arbitrary.

One problem with software is that nearly all of it has this arbitrary nature. And things become more arbitrary and indirect as one moves up from the hardware, until the entire experience for the user is arbitrary and disconnected not just from the physical hardware, but even from the form and semantics of the software that is creating the user experience.

So how and where to recapture the lost integrity of software?

Unfortunately, I don’t know of any way of doing it at the user level. At the programming level, however, it is still quite possible. The trick is to stop seeing oneself as a designer and to see oneself as an architect in the true sense of the word. In computer science, we have mistaken the meaning of the word architect; it doesn’t mean “really good high level designer.” Architect is from the words “arch tech,” and is Greek for “master builder.” To be an architect, one must build things, not design them.

This is doubly confounded because we have also mistaken the roles of design vs. building. Nothing of value is ever designed, it must be built. Sometimes good things appear to be designed, but only because some builders get really good at doing the building in their heads or on paper.* But trying to design something without going through a building process nearly always results in something that is at best sub-optimal and usually creates more problems than it solves.

Our elevation of the design myth over building also causes us to mistake the meaning of the word building. Building is not a construction process. (Construction is simply one of the operations that enable building.) Building is a growth process, and growth processes are non-linear, non-monotonic (i.e. they involve deletion as well as addition**), and are to a certain extent unpredictable.

As Christopher Alexander said:

“It creates order, not by forcing it, nor by imposing it on the world (through plans or drawings or components): but because it is a process which draws order from its surroundings – it allows it to come together”

“But if course, by this means far more order can come into being, than could possibly come into being through an invented act.”

“It is vastly more complex than any other kind of order. It cannot be created by decision. It cannot be designed. It cannot be predicted by a plan.”

And this is exactly the kind of order that we have forgotten but that Maasai herder and a man living in the house made of trees he cut himself still remember. For them, things “just work.” Literally: “stuff just works,” that is, the stuff itself works by dint of its very nature, not because of arbitrary bits glued on during artificial processes. And that’s what we need to find again in the 21st century, because the Maasai and tree-man are not living in the past, they are also living in the 21st century, and it makes no sense to call them primitive or unsophisticated when it is we who have forgotten things.


*In fact, the idea that things even can be designed is probably a myth that arose from people not understanding how skilled builders work.

** We forget that to put up a building, one often has to put up a scaffolding. We do this because we think of the building (a noun) is the result of building (a verb). But we forget that this semantic separation is artificial and is a trick of our minds. That dismantled scaffolding is as surely a part of the finished building as child’s experiences are part of the adult. Both were left behind in form, yet not in effect, since in both cases the finished product, in its very nature, bears the unmistakable marks of the construction process.

No comments: