Chapter 8. Agile Modeling

Sometimes people carry to such perfection the mask they have assumed that in due course they actually become the person they seem.

W. Somerset Maugham (1874 1965), The Moon and Sixpence

Modeling often proves to be one of several dogmatic issues within the software industry. Traditional software developers will either insist on developing sophisticated models before coding, or they will think that modeling is a paper-intensive, overly bureaucratic waste of time. Traditionally, architects often fall into the pro-modeling camp, whereas many programmers seem to fall into the anti-modeling camp. Unfortunately, both groups could improve their approaches by finding the appropriate balance between over-modeling and not modeling at all. Architects must realize they don't need to get everything right, that they need only to think through the larger issues and to leave the details to the developers, that they are much better off taking an evolutionary approach to their work. Similarly, programmers must recognize that sometimes it is significantly more productive to a sketch to think through an idea, or to compare several different approaches to solving a problem, and thereby avoid unnecessary churn when coding.

The AM methodology (Ambler 2002a) is a chaordic collection of practices that are guided by principles and values. AM is not a prescriptive process, and it does not define detailed procedures for how to create a given type of model. Rather, it provides advice for how to be effective as a modeler. AM is more an art than a science.

An agile modeler is anyone who models following the AM methodology, applying AM's practices in accordance with its principles and values. An agile developer is someone who follows an agile approach to software development. An agile modeler is an agile developer. Not all agile developers are agile modelers.