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

Well, my problem is that your statement does, again, exactly what I
complained about - you stated an answer generalized across all projects.
My point is that projects and domains differ and the risks may be
different for different people.  Doing software that will run a consumer
device is different from doing software for an extension to a corporate
HR system and the risks are likely to lie in different places.

You also assume, again, that all requirements are equally likely to be
right or wrong, which is not a valid generalization, in my experience,
in any domain I've worked in.

If I were making an internal recommendation today, I wouldvigorously
endorse short-cycle iterative development with frequent deliveries,
a test-first strategy for verification, and continuous integration, but
the prioritization would probably be for implementation-team priorities
(infrastructure) rather than customer visible (because at initiation
we don't normally know the feature set, the UI hasn't been designed, and
the hardware is in flux and 12-18 months in the future).

I imagine Scott A would say "Well, of course - do what makes sense for
your project."  My problem is, if the only rule is "Do what makes
sense," then agility wouldn't have much to teach.  So, I'd like to see a
strengthening of fundamentals (what practices work in various contexts,
what contextual features do they depend on, and why do they work), so we
can make a better stab at teaching people how to guess what will work.

scott

| From: Steven Gordon<[email protected]>
| 
| 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. 
| 
| -----Original Message-----
| From: Scott E. Preece [mailto:[email protected]]
| 
| | From: Daniel Brenner<[email protected]>
| | 
| | 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
--^----------------------------------------------------------------