[613] in magellan
Fwd: The Cooperative Game, 13 March 2001
daemon@ATHENA.MIT.EDU (Greg Anderson)
Wed Mar 14 15:21:27 2001
Message-ID: <3AAFD357.E0075F61@mit.edu>
Date: Wed, 14 Mar 2001 15:23:51 -0500
From: Greg Anderson <ganderso@MIT.EDU>
MIME-Version: 1.0
To: magellan@mit.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Good afternoon,
I'm passing along a Cutter's edge that Jim forwarded; I believe you
will find it interesting because the focus is on cooperation, being less
than perfect, and remaining inventive in reaching two project goals:
delivering the system and setting us up for the next effort awaiting
us.
Greg
>Date: Tue, 13 Mar 2001 05:20:59 -0700 (MST)
>To: edge_list@cutter.com
>Subject: The Cooperative Game, 13 March 2001
>From: theedge@cutter.com
>Sender: owner-edge_list@cutter.com
>Precedence: bulk
>
>
>Welcome to The Cutter Edge, the weekly e-mail service for IT
>professionals, provided free by Cutter Information Corp. and Cutter
>Consortium.
>
>If this article has been forwarded to you by a friend, you can
>register for your own free weekly subscription to the Cutter Edge
>at http://www.cutter.com/consortium/index_e-mail.html .
>
>
>THE COOPERATIVE GAME
>
>by Alistair Cockburn
>http://www.cutter.com/consortium/consultants/cockburna.html
>
>Some people think of software development as an engineering activity.
>That comparison is actually more dangerous than useful, as it leads
>us in the wrong direction. Comparing software development with
>engineering leads us to ask about "specifications" and "models" of
>the software, of their completeness, correctness, and currency.
>
>These questions lead in the wrong direction because we actually don't
>care, past a certain point, whether the models are complete, whether
>they correctly match the "real" world (whatever that is), and whether
>they are up to date with the current version of the code. Attempting
>to make them complete, correct, and current past a certain point is a
>waste of money. As one experienced programmer told me, "I often feel
>I am doing something good when I start drawing these models, but
>after a while I feel I have somehow passed the point of diminishing
>returns, and my work becomes wasteful. I just don't know when I have
>passed that point of diminishing returns, and I haven't heard anyone
>talk about it."
>
>To understand and locate this point of diminishing returns, we need
>to shift away from thinking of software development as an engineering
>activity and think of it as a resource-limited, cooperative game of
>invention and communication. If you have trouble imagining such a
>thing, think of rock-climbing teams. The team members must help each
>other reach the top, and they are resource limited, either by
>daylight, food, or energy. Team rock-climbing is my favorite point
>of comparison for software development, because they share so many
>key issues. I should be quite clear that rock-climbing is not a
>metaphor or analogue for software development, but rather, they are
>both members of the same class of games: goal oriented, cooperative,
>finite.
>
>In the case of software development, there is a primary and a
>secondary goal. The primary goal is to deliver the system. The
>secondary goal is to set up for the next game, which is to extend
>or maintain the system, or to build a neighboring system. Failing
>at the primary goal makes the secondary goal irrelevant. However,
>succeeding at the first and failing at the second is also sad, since
>failing at the secondary goal interferes with the success of the next
>game.
>
>Thinking of software development as a cooperative game directs us to
>more fruitful questions, particularly regarding the deployment of our
>scant people, time, and money. We are led to investigate better
>techniques for inventing and communicating, ways to get the same net
>effect by consuming fewer resources. We are led to ask about whether
>any particular piece of work is sufficient to its task of invention
>or communication.
>
>We are led to the idea that a model need not be complete, correct, or
>current to be sufficiently useful. This notion allows us to explain
>the success of many projects that succeeded despite their "obviously"
>incomplete documents and sloppy processes. They succeeded exactly
>because the people made good choices in stopping work on certain
>communications as soon as they reached sufficiency and before
>diminishing returns set in. They made the paperwork adequate; they
>didn't polish it. "Adequate" is a great condition for a
>communication device to be in if the team is in a race for an end
>goal and short on resources.
>
>Let us not ask for our requirements to be perfect, for our design
>documents to be precisely up to date with the code, for the project
>plan to exactly match the state of the project. Let us ask for the
>requirements gatherers to capture just enough to communicate as
>needed with the designers, and let us ask them to replace tedious
>typing with faster communications media where possible, possibly with
>in-person visits or short video clips of explanations. [The relative
>cost of various communications techniques is discussed more in the
>author's "Selecting a Project's Methodology," IEEE Software, July/
>August 2000, pp. 64-71, early version available online at
>http://members.aol.com/humansandt/papers/methyperproject/methyperproject.htm
>.]
>If the designers all happen to be experts and sitting close by each
>other, let us dispense altogether with any design documentation
>beyond whiteboard sketches, but let us capture these sketches with
>photos or printing whiteboards. Let us not forget that there will
>be other people coming after this design team who will indeed need
>more design documentation, but let us run that as a parallel and
>resource-competing thread of the project, instead of forcing it into
>the linear path of the project's development process.
>
>Let us be as inventive as we can be about ways to reach the two goals
>adequately, circumventing the impracticalities of being perfect. To
>exaggerate the adjectives for a moment, let us find the lightest,
>sloppiest methodology we can for whatever situation we are in. Let
>us, at the same time, be careful to make it just rigorous enough that
>the communication actually is sufficient.
>
>-- Alistair Cockburn, Senior Consultant, Cutter Consortium
>http://www.cutter.com/consortium/consultants/cockburna.html
>
>[For more on light methodologies, see the November 2000 issue of
>*Cutter IT Journal*, available from Cutter Information Corp. at
>+1 800 492 1650 or +1 781 641 9876, fax +1 800 888 1816 or +1 781
>648 1950, or e-mail service@cutter.com.]
>+++++++++++++++++++++++++++++++++++
>
>Attend SD 2001, 8-12 April, San Jose, California, USA, and Save $300!
>
>Receive up to $300 off when you register for the Software Development
>2001 Conference, coming to San Jose on 8-12 April! SD 2001 is the
>largest independent event dedicated to the development professional
>with over 150 classes in Java, C++, XML, .NET, COM+, and more.
>SD 2001 features industry-renowned speakers, special networking
>events, and an expo floor with more than 100 leading vendors.
>Visit http://www.sdexpo.com and use code SMAIL71 to receive your
>special discount.
>+++++++++++++++++++++++++++++++++++
>
>If you'd like to comment on today's Cutter Edge, send e-mail to
>theedge@cutter.com, or send a letter by fax to +1 781 648 8707 or
>by mail to The Cutter Edge, 37 Broadway, Suite 1, Arlington, MA
>02474-5552, USA.
>+++++++++++++++++++++++++++++++++++
>
>Cutter Consortium's consulting services give you direct access to
>the experts. Whatever your needs -- from off-site consulting to
>evaluations and assessments; from longer, customized jobs to off-site
>retainer arrangements -- you can be certain that the consulting
>support Cutter Consortium provides is motivated entirely by your
>organization's business and information technology needs. For more
>information, call +1 781 648 8700 or +1 800 964 5118 or e-mail
>sales@cutter.com .
>+++++++++++++++++++++++++++++++++++
>
>To unsubscribe to The Cutter Edge, send e-mail to
>majordomo@cutter.com and include the message "unsubscribe
>edge_list" in the body of the message.
>
>
>(c) 2001 Cutter Information Corp. All rights reserved.
=======================================================================
James D. Bruce jdb@mit.edu
Professor of Electrical Engineering and 617.253.3103 Voice
Vice President for Information Systems 617.253.0750 Fax
Massachusetts Institute of Technology
77 Massachusetts Avenue, Room 10-219
Cambridge, MA 02139-4307
=======================================================================
