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

I haven't the time or energy to get into point-by-point responses.  I do
understand that the Principles were not meant to be rules that could be
applied as-is to define a process, though some people do try to use them
that way.  I assume you also understand that some of what I wrote was
rhetorical, just as some aspects of the Principles are phrased to ring
nicely, rather than for maximum clarity.  [For that matter, I am
responding as much to various overstatements and oversimplifications of
the Principles that have been made here and elsewhere in the name of
agility, as to the Principles themselves.] 

"Heavy process" is rarely the real problem in software project failures
- the time spent on writing and reviewing documents is in the
noise, compared to the time wasted on rework resulting from failure to
work effectively at deciding what to build.

I agree, though, that heavy process can be an attempt to work
around organizational dysfunction that leads to that ineffectiveness and
to ameliorate some of the effects of the organizational failures.

My personal opinion is that high customer involvement in a short-cycle
feedback loop is far-and-away the most important aspect of the agile
methods, specifically because it drives toward effective decision
making.  Many of the specific processes in the various methodologies,
however, are (to my mind) individual methodologists' hobby horses.

I would also support the principle (which has been stated in this list
frequently, but is not explicitly among the Agile Manifesto Principles),
that good people, in program, project, and technical leadership roles,
matter more than the technical methods used.

I'll look for the Larman book - it sounds useful.

scott

| From: Jonathan Kern<[email protected]>
| Date: Mon, 9 Feb 2004 22:57:28 -0500
| 
| see below
| 
| -- jon
| 
| 
| 
| > -----Original Message-----
| > From: Scott E. Preece [mailto:[email protected]]
| > Sent: Monday, February 09, 2004 10: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
| 
| Please take this lightly.... though it may sound a bit harsh.
| 
| If I had known you wanted concrete answers in the Manifesto, I would have
| added a 5th bullet:
| 	We prefer 42 to any other number.
| 
| (Maybe we wouldn't have called it a manifesto either. Maybe we should have
| called them tenets, but manifesto had that cooler ring to it. This ensured
| we would get paid more for publishing it.)
| 
| Also, no one forces you to listen to us... We were just a bunch of guys who
| had experience that we hoped we could share and make everyone's development
| experiences better (or at least different). So, feel free to read RUP or
| MIL-Spec-2167A (or whatever it is -- I happily have forgotten that travesty)
| for some change of pace.
| 
| > 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.
| 
| I humbly, and sadly, submit that there is no way to measure what we do to
| any great degree. I was building a product that I had broad, cosmic, dreams
| along this line. It would have allowed projects to be run in as agile or
| heavyweight process/manner desired. It would have recorded results over
| time. It would have allowed community (anonymous) sharing of those results
| in a big repository in the sky. It would have allowed universities to pore
| over the data looking for answers to the meaning of life and of the universe
| (42). But alas, TogetherSoft execs killed the idea 2 months prior to its
| birth.
| 
| Until we have a greater sense of "data" from a large number of examples, any
| "academic-based" measurement technique is likely useless.
| 
| I'd love to be proven wrong. I gave up trying eons ago and just hunkered
| down and try to build software with "higher quality" and less "effort" and
| more fun.
| 
| >
| > 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
| 
| Can you invalidate it? By the way, you have to read a bit more into this if
| you want to isolate it and pick it apart. If you find a better means for
| collaborating on a project than with humans in the same room, looking and
| discussing the same things, I'd love to know about it. However, if I show
| someone a running piece of software that was a response to a conversation
| about a feature, I bet this is the most efficient means to cover the
| feature's adequacy at meeting their needs. I will admit that there are
| certain cultural issues that sometimes make it more comfortable for some
| people to "discuss" in email (and I have worked in such accommodating manner
| in the past). But, even there, it is better to get a translator or a
| colleague who can help!
| 
| > 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
| 
| You completely miss the point. It is not "whisper down the lane." It is the
| antithesis of that. (I'm sorry the manifesto is not more clear.) It is more
| about getting the two people who need to talk to meet face to face. If you
| think the written word in a document is better at conveying a message of
| requirements, I have thousands of data points showing how miserably we as a
| profession perform under this silly concept. Routinely.
| 
| I refer you to Craig Larman's latest work on Agile management -- lots of
| great data from lots of great sources. Thank you Craig! It is freaking
| awesome! (Agile and Iterative Development: A Manager's Guide)
| 
| > 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.
| 
| Well, duh. Yeah. Is there something in the manifesto that goes counter to
| this? What makes you think we manifesto authors don't espouse that -- not to
| mention practice it every day?
| 
| > 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.
| 
| Why do you need this? Just curious. Why are you using the computer language
| you are? Why do you use your current development methodology? How about your
| means of gathering requirements? Are all of your other methods well
| documented with lots of reference studies as to being the best that they can
| be?
| 
| Doesn't everyone just innately "know" this bit about face-to-face being
| effective because we are humans? This is a case in point. I guarantee this
| "discussion" in email land is far more damaging than were we in person. I
| guarantee I will go farther down the path of possibly irking you in this
| email than I would in person. Why? Because here, I make the mistake of
| having a one-way conversation (now that's an oxymoron!).
| 
| Does anyone really think that a team who does not communicate at all is
| better than one where the team is discussing, sharing, meeting with the
| client, running software frequently, amending understanding based on
| feedback. Do you really need data points and cold hard facts to make this
| leap of faith? of course not...
| 
| Come on in! The water is fine. Stop dabbling your toe and jump right in.
| You'll get used to it.
| 
| >
| > 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.
| 
| So what? The point isn't one of carefully calibrating your chances of
| success with a given feature. Besides, how do you know what is meant by
| "trying to gather all of the requirements?"
| 
| You may be reading too much into these maxims. Instead... let yourself go a
| bit. Maybe get a buzz on, if so inclined. Do a little Taoism or something.
| 
| Scott's point is simple:
| 	Only a fool would try to gather all of
| 	the requirements to the nth detail.
| 
| (I am asserting this for a large project, not a two-week slap together app.
| Whatever 'large' means <g>.)
| 
| Development is, unfortunately, still a lot of subtle art form. You just have
| to "learn" when to draw the line on getting details of requirements. You
| just have to learn that knowing 10% of a given requirement may be enough to
| know you need to add a class, for example, and that's enough. Do you care
| about the other 90%? Maybe not up front for this feature. You may dismiss
| the details and not delve into them after you hear the basics. Move on to
| the next requirement. Maybe this next one you need to dig deeper because you
| keep finding more information that you know has broader downstream impacts
| if you get it wrong.
| 
| Is it 50% likely that a future requirement for one year from now will
| change? Who knows? Who cares? It is a metaphor for: don't do *anything* up
| front to the nth degree. It is a guaranteed waste of time doing too much of
| any one thing. Guaranteed.
| 
| Know this. Certain things that have dependencies must be treated carefully
| in terms of planning. However, everything else can be done in any order.
| That is, it does not matter if you spend the time now or in 2 months
| gathering detailed requirements for things that are more "serial" than
| "parallel" in nature. As a matter of fact, gathering too much information
| too far in advance is arguably a wasted effort that will have to be
| repeated. (Unless you are an elephant.)
| 
| > In reality SOME BDUF is worthwhile and desirable and one of the reasons
| 
| SOME DUF, maybe... The 'B' always implies too much. It is relative, not
| absolute.
| 
| > 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.]
| 
| Did you ever question OO versus structured? Do you use OO? Is there any
| proof that OO is a better language than structured?
| 
| I'll be happier when you read Craig Larman's excellent book chock full of
| supporting facts.
| 
| For me, I never needed these facts to know this is the right way to do
| development. But, I recognize that I am weird that way. I also was an anti
| communist as a high school kid in the mid 70s arguing with my liberal high
| school teachers (and I had long hair!). Go figure!
| 
| >
| > 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
--^----------------------------------------------------------------