Chapter 6: Method, Process, andModels

Overview

Caveats to keep in mind as you read this chapter:

• All methods are someone else s idea about what you should do when you develop software. It may be useful, from time to time, to borrow from those ideas and integrate them into your own style. It is essential, however, to transcend any method, even your own idiosyncratic method, and just do it.

• Software development is like riding a surfboard ”there is no process that will assure a successful ride, nor is there any process that will assure that you will interact propitiously with the other surfers sharing the same wave. Published processes, like published methods, provide observational data from which you can learn and thereby improve your innate abilities ”just as observation of master surfers enables you to improve yourself.

• No model has any value other than to assist in object thinking and to provide a means for interpersonal communication. If you can model your objects and your scenarios in your head while engaged in writing code, and if those mental models are consistent with object thinking, great! No need to write them down. If you and your colleagues use a visual model on a whiteboard as an aid in talking about scenarios and in clarifying your collective thinking about those scenarios, and you erase the board when you re done meeting, also great! If your models are crudely drawn and use only a subset of the syntax defined here (or a completely different syntax that you and your colleagues collectively agree upon), still great! Model when you must, what you must, and only what you must.

For forty years , software development theorists focused on method, process, and modeling as the key means for improving practice, based on the belief that all software problems could be resolved if developers would give up their idiosyncratic, imprecise, and careless ways. Formally defined methods would incorporate rigorous process and modeling requirements. Following the dictates of formal methods would eliminate all vestiges of ad hoc and subjective art. Software development would be transformed, if not into a science like mathematics and physics, then at least into a solid engineering discipline solidly grounded on a science of computing. Models would have precisely defined syntax (preferably based on a kind of predicate calculus), and all semantics would derive from formal transformations of that syntax. Properly constructed models would contain unambiguous truth, and one model (a data flow diagram, perhaps) could be mechanically transformed into another (source code, for example).

A process could be defined that would describe in precise detail each step required to move from vague idea to functional solution. At each step in the process, the developer would know exactly what to do, how to elicit required information, and how to express that information in syntactically correct models.

Methods of this sort could be expressed as automated tools. It would be possible to remove significant numbers of human developers from the process ” especially those pesky and annoying programmers. Computer-aided software engineering (CASE) tools would allow a properly trained analyst to construct precise models, which would then be transformed into error-free code at the touch of a button (click of a mouse). It would, in fact, be possible to build a repository , an ultimate CASE tool that would allow the automatic generation of computer programs and systems in response to a change in business requirements ”without the intervention of analysts or programmers.

The vision of the theorists was compelling ”and highly salable to managers, who rushed to adopt the latest advances, buy the latest tools, and pay for audits that would document their compliance with the latest process standards.

Unfortunately for all, the dream was never realized in practice.

During the same period, practitioners ”lacking such grand vision ”focused on discovering and sharing heuristics and practices grounded in experience rather than theory. The art and craft followed by expert developers was transmitted mostly via oral tradition, mentoring, and informal mimicry. Real improvements in software development were realized ”but non-self-consciously, ^[1] in the form of a shared culture and oral traditions.

After the fact, formal methodologists adopted many of these practitioner innovations and recast them in terms of their pet theories (sometimes ignoring the origins of their insights ). This recasting allowed the methods of such methodologists to give the appearance of supporting new innovations without initiating any substantive change. In fact, innovations were all too often redefined by the methodologists as being nothing more than some feature already present in the method: We have been doing objects since 1960; only we called them ________. This, and similar statements, were expressed by innumerable mainstream developers and methodologists in response to innovations.

XP and the other agile methods represent the first attempt by practitioners to systematize (not formalize) practice in such a way that it could be perceived as a legitimate alternative to a formal method. So legitimate in fact, that the backlash from mainstream formal methodologists is intense . XP is nothing more than good software engineering. RUP (Rational Unified Process) and CMM (Capability Maturity Model) are just as agile as anything coming out of the Agile Alliance. XP works only in certain niches (which are not really important anyway), while formal methods are required for most development. XP is nothing more than a fad, a way for unemployed Smalltalk programmers to get jobs again.

The jab at Smalltalk programmers alludes to important relationships among XP, methodology (in general), and object thinking. To fully see the connection, it s necessary to make one last historical foray ”a brief recap of object-oriented methods and models that have been advanced over the past 20 years.

^[1] Christopher Alexander differentiated between self-conscious and non-self-conscious processes in architecture. The latter arise only in affluent societies with universities and give rise to architectural theories whose merits are based on abstract meta-arguments rather than on any connection with practice or actual manifestations . Alexander, Christopher. Notes on the Synthesis of Form . 1968.