Downloaded from the Internet Archive: https://web.archive.org /web/20000819045916/http://members.aol.com/acockburn/papers /methyspace/methyspace.htm The Methodology Space Alistair Cockburn
[email protected] Human and Technology Copyright notice: This is Humans and Technology technical report HaT TR.97.03 (dated 97.10.03). It may be submitted for reviewed, dead tree publication, at which time the copyright may transfer to that publisher. This copy is being web-published for early peer dissemination. Note from the author (Alistair): Between October 1997 and October 1998, I have extended the model somewhat, to include cultural aspects of teams. This then, represents the first pass at a description of Methodology. counter is since resetting March 15, 1999 Abstract Many people are unclear as to what a methodology is, what it should contain, what it should optimize, or how it should be used. Discussions about methodology tend therefore to be emotional and nonproductive. The purpose of this paper is to examine the space of methodologies, to provide a basis for emotionally neutral discussions about where any nominated methodology fits. It examines what one is and looks like, why multiple ones must and will coexist, what principles apply, what one might optimize and where one might be applicable or not applicable. No particular methodology is espoused in this paper, since it aims to provide a neutral basis for discussion. Section 0. Context, Problem, Main Result, Sequencing Context into which this paper fits At the current moment, early 1998, methodology discussions proceed without much in way of ground rules, hence also with emotional charge and often without progress. This paper addresses the ground rules. In the OO community, the word "methodology" is often used to mean a set of (mostly drawing) standards of the type UML, Shlaer-Mellor, OMT, Booch, or Coad. It may also indicate a set of design techniques such as CRC cards, role modeling, or semantic modeling, or transformational design. People who use the term in this way argue over how best to draw, how best to design, and whether such minor parts of project life are even worth arguing over. In large consulting houses, the word "methodology" means the role 1 von 27
definitions, job descriptions, activities and exchange deliverables of everyone on the project. Some consulting houses have rows of ring binders describing their methodology. Some can generate customized rows of ring binders on demand from a tailorable repository. Both uses term cast emotion (usually fear and loathing mixed with hope) into a discussion. People on projects recognize that they need some element of a methodology, but typically feel that the first definition of methodology represents only a small part of their work, and the second will be stifling. The result is distaste for the discussion of methodology, and typically unproductive dialog when such a discussion starts. The Problem this Paper Tackles This paper addresses the more serious matter of creating a fair dialog between people of opposing views, and the interesting but less critical matter of creating a taxonomy for methodologies. The paper succeeds if two people can carry through a conversation about methodology, understanding that they will disagree on final choice, while understanding each other's vocabulary, context and value system. It addresses the following specific questions: What is a "methodology?" What are its bounds, what are its dimensions? How might one fruitfully compare two methodologies? Is there one or must there be many? If many, how would one know which one or elements of one to adopt? Is one "better" at some thing or in some way than another? Must they be big, and if so, how should one best deal with their size? On the way, the paper splits open the me