Top positive review
A Challenge from Common Sense
on February 3, 2003
An adept application of common sense--and the author's significant experience--to the use of models in software development.
A model can be almost anything that developers make to describe the software that they build--just like an architect's drawings.
A given software development effort might call for any number of different types of models including data models, class models, sequence diagrams, dataflow diagrams, statechart diagrams, etc. The set of models used on any particular project will depend partly on the nature of the project and partly on the preferred methodology of the software developers.
Agile Modeling (AM) is not itself a software development methodology. It is a collection of principles and practices to follow when using models to develop software according to a methodology like Rational Unified Process (RUP) or eXtreme Programming (XP). Many of the practices derive from an application of XP concepts.
AM challenges a number of practices widely followed (or at least preached) in organizations developing software:
1. Specializing personnel in producing a single type of model
2. Dedicating work sessions to producing a single type of model
3. Saving models after the software is developed
4. Keeping models up-to-date during and after the development project
5. Using sophisticated software to assist in modeling
6. Finishing models before coding software
AM does not in all cases prohibit these practices, but it emphasizes that the purpose of a software development project is to develop software--not just to develop models. The practices of AM help to keep models in their proper subordinate relation to the working software that is the true goal of any development project.
People with more luck than experience might doubt the need for agile modeling. Please accept from a reader with much more experience than luck an assurance that the need is great. This reader has personally witnessed development projects undertake the costly construction of models having at best a tenuous relation to the software to be developed.
It should in fact come as no surprise. Who would not agree that it is easier to waste other people's money than to abandon one's own obsessions?
At any rate, Mr. Ambler tries to keep us on track with this excellent book, challenging us to use models but to stay focused on software.
Different readers are likely to be challenged to different degrees by AM's various principles and practices. This reader easily accepted, for example, the practice "Create Several Models in Parallel," counseling us to construct multiple model types simultaneously and to eschew the antipatterns of "Single Artifact Developers" and "Single Artifact Modeling Sessions" (pp. 47-50).
The principle "Maximize Stakeholder Investment" proved more challenging. It counsels that project stakeholders (i.e. the businesspeople commissioning the development project)--not software developers--ought to decide whether to develop software documentation (p. 37). True, the stakeholders pay the bills, but architects and accountants also have paying clients who are nevertheless not able to dictate everything about their work. Clearly software development should have professional standards whose suspension may not be commanded even by a paying client.
Another challenge for this reader: "Agile modelers typically do not bother to distinguish between the different "flavors" of modeling, . . . (p. 252)." Here Mr. Ambler is writing about what Martin Fowler calls "perspectives"--conceptual, specification, and implementation--that a model might take on its subject. These perspectives correspond to the business analysis, system analysis, and system design phases of a software development project.
In his "UML Distilled," Mr. Fowler differs sharply from Mr. Ambler: "Understanding perspective is crucial to both drawing and reading class diagrams. . . . it is very important to separate the specification perspective and the implementation perspective (p. 52)."
Or does he? Mr. Ambler hedges his position in the very same sentence: ". . . they just model appropriately as the situation calls for." Now, how can one "model appropriately" if one does not first "bother to distinguish"?
Elsewhere too, the advice of AM can seem equivocal (or is it "nuanced"?). The practice "Collective Ownership" allows everyone on a project to work on any of the project's models. This "power to the people" is however greatly diluted by the practice "Model with Others," prohibiting anyone from modeling alone. Further dilution appears in the case study, where it is recognized that one would be foolish to work on a database design without consulting "Brendan, the database administration (DBA) expert on the team (p. 288)."
It is interesting to compare Mr. Ambler's populist principles for teamwork with the more elitist principles of Frederick Brooks in "The Mythical Man-Month." Mr. Brooks begins his third chapter by citing the "wide productivity variations between good programmers and poor ones." He derives from this observation a software development organization patterned after a surgical team--with one operating surgeon and a small flock of assistants.
Although starting from opposite principles, Brooks and Ambler finish peculiarly close in their team-building practices. A la XP, Brooks's ideal team pairs the "surgeon" with a colleague equally gifted though less experienced. Inversely, Ambler approaches Brooks by listing in Chapter 12 the qualities of superior software developers. "Everyone can learn from everyone else" is one of the "supplementary principles" of agile modeling, but clearly some people have less to learn than others.
Mr. Ambler seems well read. He frequently cites related books throughout the text, adding a special recommendation here and there. One of these recommendations surprised this reader, who was astounded that Mr. Ambler found "UML for Database Design" by Messrs. Naiburg and Maksimchuk "a good read (p. 170)." You may find this reader's differing opinion filed with Amazon.com
Our difference on this small point serves only to highlight the strength of this reader's recommendation.
This is a provocative and well-reasoned explication. Agile Modeling will leave its mark.