Purpose and Use of Method


Methods come in many guises. The simplest is nothing more than the adage, If at first you don t succeed, try and try again. Hacking, trial and error, and rapid prototyping are examples of methods based on this precept. Iterative development approaches ”based on exploration, trial and error, and incremental expansion from small working systems ”have been used and advocated almost since the  inception of commercial computing but have never been accepted as official methods .

Other methods are more prescriptive, instructing the developer as to what to do and when to do it. The simplest form of a prescriptive method would be a checklist, such as that used by pilots for each phase of flight. Such checklists consist, essentially , of a set of questions of the form, Did you remember to do this action? Actions that need to be done in a particular order simply have their reminder questions occur in the necessary sequence.

Most software engineering methods are highly prescriptive ”with precise instructions as to what and how to develop software at each meticulously defined step in a carefully arranged process. They are based on a value system that incorporates a basic mistrust of the human worker. Such methods can become highly complex and comprehensive as the checklist expands to include documentation that must be produced to confirm that each action did in fact take place, as well as syntax that specifies the exact form of the documentation so that it is known that the action was done correctly. (I have seen one such method that filled almost 20 volumes ”defining each step, describing each document or artifact produced, and including algorithms for determining the correctness of all artifacts produced.)

Between hacking and prescriptive overkill is the realm of formal, informal, and aformal methods.

Formal methods tend to be prescriptive. They are characterized by a large number of models each of which requires a reasonably complex syntax, they are filled with rules and techniques that assure proper use of the method, and they are fairly strict in terms of activity sequencing. Most offer a promise of removing human developers, to some degree, from the development process ”via code generation, for example.

Informal methods require fewer models with simpler syntax, demand fewer activities, and offer heuristics instead of rules and techniques. Most pick a single activity ”programming, for example ”and elevate it to primary status while suggesting that all other activities are valuable only insofar as they support the primary status. XP shares these characteristics and would be called an informal method.

An aformal method [7] would reject the idea that any task, model, syntax, rule, technique, or heuristic has any intrinsic value. Such things are valuable only to the extent that they support or assist the innate capabilities of the human developers engaged in a particular task at a particular moment in time. Both formal and informal methods are seen as a kind of exoskeleton that might offer some protection, but at the cost of severely limiting the being enjoying that protection. Improving the innate character and capabilities of the human developer is the alternative to defining an external method, for an aformalist. Aformalism might also be considered master practice. Craftsmen have internalized those aspects of informal method and practice most germane to their art and have transcended them.

An analogy to chess playing might illuminate the relationships among method categories. A beginning chess player follows rules and defined procedures (they are formalists), while a journeyman (informalist) relies on patterns and heuristics. A grandmaster has internalized and transcended the informal to become an aformal player.

Methods themselves are less important than the culture shared by those that embrace a method. Software engineers , for example, represent a culture enamored of formal methods (even if they cannot use them). (There are exceptions to this rule: Dave Thomas, for example, sees engineering as creative and aformal problem solving independent of any formal method or process. It is hard, however, to find that attitude reflected in software engineering texts .) Those methods are considered necessary and desirable because the method expresses the set of presuppositions , values, and worldview shared by the members of the culture. Formalists like formal methods ”an obvious truism.

Managers; academics ; software engineers; computer scientists; and proponents of UML, RUP, and CMM all tend to be formalists. Practitioners , as Robert Glass has shown, generally are informalists. XP and object thinkers aspire to be aformalists.

Methodological conflicts, therefore, are really cultural conflicts. When an advocate of RUP asserts that RUP is agile, he or she is making an irrelevant statement. Of course, RUP can be agile ”it is merely a tool, after all, and the practitioner has the choice of how, when, and why to use that tool. But someone from the culture that values RUP cannot be agile. (OK, technically, will not be agile. OK, OK, is very unlikely to be agile.) The same mostly nonconscious worldview that leads to adoption of RUP and UML will prevent the use of that method in any but a formal way unless a constant, conscious, and deliberate effort is made to adopt the agile worldview and cultural values at every step of development.

Formalists will advocate methods that are focused on the production of computer artifacts (software programs). Such methods will liberally employ terms such as software engineering and will stress correctness and both syntactic and semantic integrity. It is held that such methods are capable of producing a correct solution to an unambiguous requirement, prior to the expensive process of committing it to code. Code generation is then a happy byproduct of formal methods. The major drawback, of course, is that the effort required to produce the formally correct models is essentially the same as (or more than) that required to code and test. (Code, ironically, is far more amenable to formal testing than any abstract model. As Ken Auer says, Bubbles and arrows never crash; they also never run! ) This makes for a steep learning and overhead curve for those using this kind of method. They will also suffer from some degree of mismatch between the real world and the formal world they attempt to describe. The real world is far fuzzier, flexible, and illogical than any formal method can accommodate.

Informalists are more likely to focus on methods that support negotiated understanding ”for example, the informal communication-oriented methods such as joint application development (JAD) and CRC. To the extent that they adopt modeling techniques, informalists see the models as a means of communication ”not an artifact with intrinsic value. It is clearly recognized that such models are bound in terms of time and are meaningful for the group involved in their creation. That is why the development group must include users, managers, analysts, programmers, documenters, maintainers, and so on. They will understand the models only if they participate in their construction. Reinhard Keil-Slawik [8] shows how such models (including code) serve as a kind of external memory for the group that created them and works with them. The primary problem with these methods is the lack of technique for translating the human understanding of a solution into a computer understanding. The computer, after all, is a formal machine and can operate only on formally defined products. This explains the tendency of informal methods (XP, rapid prototyping, open source, and so forth) to focus on programming ”the actual interface between formal machine and informal developer.

Aformalists appear to reject method entirely. Observation, however, reveals patterned behavior and tasks performed in a sequential manner. Models are constructed (on whiteboards , Post-It notes, and 4 — 6 cards more often than with the use of an automated tool), giving those models a relatively short half-life. Aformalists do not reject method so much as they reject the idea that methods and models have any intrinsic value apart from those using them in a specific context.

In one of the Alien movies, Sigourney Weaver s character fought the alien monster using a mechanical exoskeleton. This exoskeleton greatly increased her human strength by amplifying her human movements with electromechanical means. Formalists tend to see method as a similar kind of exoskeleton, one to be wrapped around a human developer in order to amplify his or her skills.

Aformalists viewing this scene would be mildly impressed by the magnification potential of the exoskeleton but would be completely appalled at  the cost required to gain that advantage. The human becomes a mere part in the  machine and is severely restricted to a range of actions determined by the exoskeleton and its designers. They would note that continued use of such mechanical strength enhancement devices would perpetuate the physical weakness of the human and, likely, increase those weaknesses (exaggerating the importance of the exoskeleton) over time. In addition to the limitations imposed by the designers of an exoskeleton, use of one adds new complexities ”how to get in and out efficiently in response to perceived need ”and vulnerabilities ”what to do when your exoskeleton is in the next room when the alien appears?

Object thinkers and extreme programmers reject the method-as-exoskeleton approach in favor of a method “as “weight room idea. A human uses mechanical weights and machines in a gym to increase his innate capabilities ”to make his own muscles stronger and more reliable. Using a more cerebral metaphor (and one therefore more appropriate for object thinking), Kent Beck suggests using method and even XP practices as if they were etudes (musical exercises designed to help the musician internalize certain skills and techniques). Etudes are used for practice, to increase and discipline the innate capabilities of the musician so that she can then go on stage and perform music. [9]

Object thinkers and extreme or agile developers find value in method only to the extent that it helps them become better practitioners. The method itself should wither away as developer skills increase until it becomes the merest vestige required to act as a reminder or trigger for the human developer to apply his or her enhanced skills when and as appropriate. Kent Beck suggests that there are three XP maturity levels: out of the box, adaptation, and transcendence . These levels correspond nicely with the formal, informal, and aformal typology introduced earlier in this chapter. (Except XP would never have a formal level ”substitute rote performance for formal in the XP context.)

This is not a new idea. The south Asian philosophy of karma yoga is grounded in the idea that right actions allow you to minimize the consequences of your actions sufficiently that you can maximize your chances of enlightenment. Aristotle suggested, Wear the mask of a good man long enough and you become that good man. David Parnas suggested some very good reasons for faking a rational design process even when you can t actually follow such a thing. Christopher Alexander stressed repeatedly that a pattern language is but a gate that must be passed through and left behind before you can actually practice the Timeless Way of Building.

For object thinkers, method is never an end in and of itself. There is no intrinsic value in either method or process. Both are useful only to the extent that they provide practice in the use of, and a means of enhancement for, innate human capabilities. Within the context of this worldview, it is possible to ask whether some methods, some tools, some models are more suited to promoting object thinking than others. And the answer is yes. To determine which methods, tools, and models are the most efficacious, the following criteria can be used:

  • The method, tool, model, or process cannot substitute its own goals in place of those articulated in object (or XP) philosophy.

  • Each task advocated by the method and each model created using the method must contribute to the realization of basic goals.

  • The models, vocabulary, and syntax associated with the method and its models must value expressiveness over correctness. Models must evoke knowledge in the head of the developer instead of making pretensions to unambiguous representation of that knowledge.

  • The methods and models must

    • Provide support for natural decomposition and abstraction of problem (enterprise) domains. This requirement refers back to the simulation notion behind SIMULA and the object paradigm.

    • Recognize a need for two complementary processes: one focused on domain modeling and the second on application assembly.

    • Include heuristics for discovery and evaluation. Heuristics should be grounded in appropriate metaphors to facilitate learning.

    • Include heuristics or metrics that allow you to measure progress and the goodness.

[7] Aformal method is almost, but not quite, an oxymoron. Some familiar aspects of method remain even in the most aformal approaches to software development.

[8] Floyd, Christiane, Heinz Zullighoven, Reinhard Budde, and Reinhard Keil-Slawik. Software Development as Reality Construction . New York: Springer-Verlag, 1992.

[9] It is true that some etudes are themselves sufficiently beautiful that they get played in concert, just like any other kind of music composition. This does not detract from the intent behind their creation.




Microsoft Object Thinking
Object Thinking (DV-Microsoft Professional)
ISBN: 0735619654
EAN: 2147483647
Year: 2004
Pages: 88
Authors: David West

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net