Re: [AM] ANN: Mashing Deadly Myths

At 05:14 PM 2/23/2004, Scott P. wrote:
><snip>
>
>---
>| 4. We need a team of specialists. ... What's really necessary is a team
>| of generalizing specialists.
>---
>
>I have no problem with this if you describe a "generalizing specialist"
>as "someone who know enough about the roles involved in the project to
>interact effectively with the people in the related roles". On the
>other hand, if you intend it to mean "every member of the team is
>capable of performing every role", then I disagree vigorously.

A generalizing specialist is someone with one or more specialties (or is 
working on them) and a general knowledge of development and ideally the 
business domain.  I wouldn't expect everyone on the team to be an expert 
data modeler, for example, but I would expect them to understand the 
basics, appreciate why it's important, and be willing to work with 
someone(s) with that expertise if needed.



>Just as you wouldn't expect the person who designed the battery on a
>cell phone to be qualified to also design the antenna, you shouldn't
>expect that the person who designs the user interface is capable of
>designing the code that implements the it,

I wouldn't expect them to be experts at both, but I would expect them to 
understand and appreciate the basics.  Otherwise they won't be able to 
interact effectively and they will run the risk of stepping on each other's 
feet.


>let alone of designing
>Level 1 of the air interface stack or speech coding algorithms that will
>run in the DSP.  They just need to know each others' domains well enough
>to communicate about needs and interactions at the interfaces between
>domains.


Yes.


>---
>| 5. The information is lost if it"s only in the code. This statement is
>| clearly false: How can it be lost if you know where it is? The
>| information might be lost to them if the folks in question can't read
>| source code, but isn't the real problem a lack of development skills?
>| Organizations that subscribe to this myth will invest far too much in
>| documentation, increasing their costs, while slowing themselves down.
>---
>
>"The code" does not represent all of "the information".

Never said that it did.  See 
http://www.agilemodeling.com/essays/agileDocumentation.htm.


>   It says nothing
>about what was intended, how it was expected to be used, or why it is the
>way it is (modulo any comments people felt inclined to add).

Yes, you can still write external docs, nothing wrong with that, as long as 
you focus on value.


>   Stonehenge
>is a nice example - we've got the artifact, but we have only speculation
>about what it's for and how it was used.

And yet it's one heck of a tourist attraction.  In fact, it's 
attractiveness might be the result of the mystery surrounding it -- it 
would be hard to put a good spin on it if we were to discover that a few 
people got drunk one night and decided to put it together for a joke.



>---
>|
>| Myth-Masher: Again, this solution calls for building teams of
>| generalizing specialists, people with the confidence and ability to work
>| with the wide range of artifacts created during development. If you
>| focus on writing high-quality code and putting documentation in the
>| single most appropriate place (which is often the code), people will
>| start to see this as an incredibly effective way to work. All I?m
>| suggesting is that you apply the fundamentals of data normalization, the
>| desire to store information in one place only, to documentation.
>---
>
>I have no complaint with this suggestion, just with the original
>assertion that "the code is enough".

Please reread what was written.  I didn't assert that at all.



>---
>| 6. We need a detailed process definition. Just as bureaucrats think that
>| you?ll read documentation, they also assume that you?ll read and then
>| follow defined software processes. The only time that I?ve ever seen
>| anyone read a process definition is when they?ve never done the job
>| before....
>|
>| Myth-Masher: In reality, your process definition efforts are usually for
>| naught. You?re better off developing a high-level overview of how things
>| should work, producing templates and examples of key artifacts, and then
>| ensuring that everyone is given the training and mentoring they need to
>| gain the skills they require.
>---
>
>My experience is that you can't build the training, templates, examples,
>and overview, without doing all the work that would produce the detailed
>description.

There's several firms which train people in XP that would disagree with 
that statement.  ;-)


>  That is, the writing of the detailed description is a wart
>on the side of the effort of developing the information it represents,
>which you DO need.

Sounds like a pretty big assumption on your part.



>| 7. We need to review this artifact. Too much faith is put in reviews and
>| inspections, and when they?re done well in the right situations, they do
>| produce results. However, reviews are compensatory practices?they
>| compensate for communication barriers such as disparate locations, which
>| result in inconsistencies between artifacts; little or no artifact
>| sharing, which allows people to get on the wrong track without being
>| caught for awhile (if ever); and overspecialization of skills, which
>| results in narrowly focused decisions that ignore the bigger picture.
>---
>
>Reviews and inspections are different animals. Reviews are intended to
>align thinking, inspections are intended to identify defects.

Yes, but both are still compensatory practices.



>In organizations where colocation, simultaneity, and continuous
>involvement are not practical, reviews are critical.

Yes, because they compensate for this communication barrier that you've 
chosen to erect.  Perhaps tearing down the barrier is a better option.


>  If you want to
>develop rules that apply only to projects small enough to get every
>stakeholder involved in every decision, your audience is a very small
>subset of the software development world.

Actually, I would prefer that people understand the implications of what 
they're doing and then act accordingly.  Most people don't understand the 
risk, and the cost, of tolerating poor communication environments.

My experience is that teams can be dramatically smaller when you choose to 
work that way.  The Florida/Minnesota missing persons case study from the 
Chaos group is a perfect example of that.  Minnesota assumed that they 
needed a small team and got the job done, Florida assumed they needed a big 
team to build the same system and blew millions of dollars over several 
years without delivering.  I suspect that the Florida people didn't know 
any better.



>Inspections, on the other hand, are just one (particularly effective)
>way of finding defects in artifacts. There are other means to the same
>end, and the relative costs and benefits will be specific to your
>organization and project.

Inspections are great compensatory practice when you're not able to adopt 
practices such as collective ownership, coding/modeling standards, 
continuous integration, and pair programming/modeling with others.  I find 
them far less effective in high-communication environments, but in 
low-communication environments they can be really good when done 
right.  Use the right technique for the job.

- Scott

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