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

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

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