Models, Models, Models

There are at least three meanings of "model," and each one implies diverse usages and connotes different processes.

One meaning for the word "model" is a sketch. For example, we might sketch out the shape of a wing on the back of a beer mat, show a few lines indicating air flow, and write an equation or two describing how the two interact. The sketch is not precise or complete, nor is it intended to be. The purpose of the sketch is to try out an idea. The sketch is neither maintained nor delivered. Agile exponents are willing to sketch out classes and use cases (the latter are akin to "user stories") and perhaps even use the UML to do it. There's no fight here: Even the most extreme folk use sketches to outline their ideas for the code.

A second meaning for the word is the model as blueprint. A physical model of an airplane in a wind tunnel is one example. More commonly, we think of a blueprint as a document describing properties needed to build the real thing. In other words, the blueprint is the embodiment of a plan for construction.

The connotation of model-as-blueprint causes conflict. The very idea of a "blueprint" evokes images of factories and manufacturing, together with uncreative drones. In an environment that's 80% construction and 20% design, it makes sense to view the blueprint as the plan that is predictive of the construction work to be done. "Heavyweight" processes have encouraged the idea of model as blueprint; the manufacturing analogy is drawn repeatedly in the Software Engineering Institute's Capability Maturity Model (CMM; see http://www.sei.cmu.edu/cmm/cmm.html), for example. But we know software is a creative new-economy notion, not at all like old-fashioned manufacturing. To the contrary, software is known for its creative aspects, more like 80% design and 20% construction. In this case, developers need to be adaptive rather than predictive in their relationship to models, which effectively puts the kibosh on the use of models as blueprints.

The third meaning for the word is the model as an executable. The model of the airplane can be transformed into the real, physical airplane. When we build an executable UML model, we have described the behavior of our system just as surely as we would have had we written a program in Java. Indeed, when you have a software model that can be compiled and executed within the confines of the functional and nonfunctional requirements, there's no need to distinguish between the model and the "real thing." That's the special property of the software realm.

Consequently, executable models, because they can be automatically translated into code, are as suitable for agile processes as code. Moreover, the degree of abstraction introduced by models is more suitable for what agile processes strive to achieve: bridging the gap between customer and developer, and rapid feedback to verify that the developed system is correct.