Re: [AM] Why Traceability?

Brad Appleton <[email protected]> Tue, 16 Mar 2004 15:35:21 -0600
Newsgroups gmane.comp.programming.modeling.agile
Message-ID <[email protected]>
On Tue, Mar 16, 2004 at 09:41:06AM -0500, Paul Oldfield wrote:
> <rant mode>
> Of all the people that quoted Impact Assessment as the
> reason, I have yet to find a credible explanation unless
> we assume a level of incompetence in the developers of
> the existing code that would surely render any traceability
> information worthless.  

I don't believe so. I believe the assumption being made is
that you have a single, small, colocated team and a small
enough system (under a million lines of code) that people can
reasonably wrap their brains around the whole domain model.
And impact analysis is often about doing enough analysis
in order to find out whom to communicate with in order
to obtain an estimate (as opposed to doing the estimate
itself). See my previous post on this thread for more
details.

People simply have limits to the quantity of complexity they
can effectively deal with - thats a fact rather than an attack
on competence. So the main ways we know of are to strip
away what you can live without, and then if the rest is still
too complex, either "divide & conquer" or "conquer & divide".

"Divide & Conquer" parcels the complexity across multiple
teams, organizations, phases, projects, products, etc. And
then pays the communication and coordination price for being
less able to see the forest for the trees.

"Conquer & Divide" (as XP has sometimes been described) parcels
the complexity by managing its scope, and the granularity of
changes/requests/iterations/releases by keeping them as small
and simple and fine-grained as possible for the current "timebox"
and save the rest for subsequent reprioritization and feedback
adjustment/correction. Instead of fragmenting the people and
the communication it fragments system size/scope and grows it
in a piecemeal "emergent" fashion based on tight-feedback of
small chunks so that the size and scope of the people doing
the work can be kept simple.

Instead of dividing up the solution over people using a "master plan",
Agile prefers dividing up the problem over time using "organic growth".

It's a very big shift in mind-set for some folks to make,
and very scary leap at that.

-- 
Brad Appleton <[email protected]> www.bradapp.net
  Software CM Patterns (www.scmpatterns.com)
   Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost

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]

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------