RE: [AM] justify modeling (Why Model?)

In the context of the original question, I was saying the following:

In my experience the biggest risks at the beginning of a project all involve the requirements:
- The customer may not really know what they want or need.
- The customer may know what they want, but it really is not what they need.
- The customer may not be able to communicate what they want or need in a way that the developers can understand.
- The developers may misunderstand what the customer has communicated.
- The requirements and/or the understanding of the requirements may change radically during the project.

Attempting to model all the requirements at the beginning exacerbates all these requirement risks.  Modeling up front would ameliorate the risk that my team could not evolve a suitable architecture or find a way to satisfy all the known requirements doing them in priority order instead of all at once.  However, I consider this a much smaller risk than assuming that we have obtained the correct requirements and understood them correctly at the beginning of the project.

Creating working software in the first few weeks of the project by implementing a few of the most central, highest utility requirements in a way that permits easy change and extension using a simple OO design is the best way in my experience to reduce the requirement risks.  Doing so:
- Makes it much easier to validate mutual understandings and inexpensively repair any misunderstandings.
- Establishes a good rapport and customer confidence that we can actually deliver something other than paper.
- Makes it much easier for the customer to visualize what they have so far and what is missing.
- Allows the developers to gain much more information before committing to a central architecture.

Doing so also reduces other risks, such as technology risks - we have actually built something with the target technology and seen if it will work in the customer's environment.

I believe there are much greater risks of requirements misunderstanding when attempting to do the same things with models instead of working software.  While a really smart customer might catch on to modeling well enough to catch some things we have misunderstood, it is a very rare customer who will catch if something is missing altogether.  If mistakes are discovered later when the software is built on top of many weeks of modeling artifacts, then repair and change is much more expensive, and even worse, demoralizing for the customers and the developers.

Nevertheless, some informal white board modeling can be invaluable for doing the simple OO design of how to implement an individual software requirement or how to integrate it with the simple OO software already developed.

I do not have any proof that this is a better approach than up front modeling other than my personal experience, the personal experience of many other people, and my common sense.  I do not believe that an experiment to establish which is better could be defined and executed practically.  I would also concede that the relative merits will vary among domains and organizations.

Steven A. Gordon, Ph.D. 
Manager, Software Factory 
Arizona State University 
PO Box 875506 
Tempe, AZ 85287-9509 
http://sf.asu.edu 
(480)-727-6271


-----Original Message-----
From: Scott E. Preece [mailto:[email protected]]
Sent: Monday, February 09, 2004 8:18 AM
To: [email protected]
Subject: Re: [AM] justify modeling (Why Model?)



| From: Daniel Brenner<[email protected]>
| Date: Mon, 09 Feb 2004 09:40:19 +0100
| 
| Steven Gordon wrote:
| > So, I would want my developers to do just enough informal modeling to write reasonably simple, well-designed code for the stories they are implementing.
| 
| do simple models imply simple code? Creating a simple model is as
| difficult as writing simple code? (ok, you can leave out a couple of
| elements to make it easier to understand/nicer to look but is this what
| you want?)
---

This is one of the many great unanswered questions that the Agile
manifesto principles accept on faith.  There isn't even broad agreement
on what "simple" means.  There is some research (see Measuring Software
Design Quality, by David Card and Robert Glass, and work by the Zages at
Ball State on design metrics) that points to lower defect rates in
simpler designs (where simple is measured in terms of things like number
of arguments, fan-in/fan-out, etc.). I don't know whether there is
work specifically looking at ease of extension/modification.  However,
the notions of simplicity in those metrics are very specific and
somewhat different from those mentioned in some of the agile literature.

Similarly, the Principles say  that face-to-face conversation is the
"most efficient and effective method of conveying information", but I
haven't seen any pointers to research validating that statement.  Anyone
who played the telephone game at a party as a kid knows that
face-to-face conversation is prone to meaning drift even in trivial
message transmission.  I tend to think that face-to-face conversation is
best bolstered with supporting artifacts; decision-making sessions are
aimed more at creating new artifacts or modifying existing ones, but
information-transfer sessions (mentoring, teaching, sharing) are best
supported with prepared materials designed to convey the information.
I'd be very interested in work that explored different forms of
interaction and looked at accuracy and depth of retention of information
conveyed.  I'm sure there must be psych and education literature in the
area; what I've seen in the agile books I've looked at recently was a
graph of "communication effectiveness" with no attribution or references
to supporting studies.

In the "Agile Modeling" book (which I like a lot), Scott says something
close to: "If you try to gather all the requirements up front, some of
them may change. You're as likely to be wrong as right."  The leap from
"some of them will be wrong" to "the probability of any individual
requirement being correct is 50%" is totally unsupported. In my
experience the probability is substantially higher than 50% across the
board and most projects can categorize individual requirements as having
higher or lower probabilities of change, with reasonable accuracy.
In reality SOME BDUF is worthwhile and desirable and one of the reasons
agile relies on capable people is that those people have developed the
ability to recognize the difference between BDUF that has a high
expected payoff and BDUF that has a high risk of washing out.

I really do believe that a lot of the principles of agility are true
at some level, but I continue to be put off by the way they are
presented as absolutes and by the way they tend to be supported by
assertion, rather than evidence. [I still haven't gotten to Boehm and
Turner - I'd be surprised if Barry didn't address some of these issues.]

scott

-- 
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il  61820  
e-mail:	[email protected]	fax:	217-384-8550
phone:	217-384-8589	cell: 217-433-6114	pager: [email protected]

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------