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
--^----------------------------------------------------------------
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
--^----------------------------------------------------------------