Re: [AM] Why Traceability? Lean Traceability?

On Wed, Mar 17, 2004 at 05:22:49PM -0500, Paul Oldfield wrote:
> Understood.  However, this *does* seem like a strategy for
> use where the ripple effect has not been beaten into
> submission.  Though where the changes affect the existing
> interface, or the existing 'contracts' on that interface, the
> changes may well ripple despite our best prior efforts.

Agreed.

> Again understood.  This seems to be a strategy for use where
> change is feared.

That is one circumstance. I think there are others. I know of
some (and hear of many more) persons and organizations whose
idea of "maintainability" is not to minimize dependencies thru
the use of design principles/patterns but who instead regard
maintainability to mean "everything I need to know has been
thoroughly documented somewhere". I even suspect this is
the case for the majority.

Another is good old BDUF. One can still do BDUF and BRUF and
still not fear change, but still tackle the problem in such a
that uses very LONG test-feedback cycles instead of very small
and short ones.

Another is good old "stovepipe syndrome" or "warring tribes"
syndrome in the organization (something that I've all too often
seen despite the best intentioned and most technically adept
and most agile embracing/proficient developers). Even if 
the developers have darn near everything else in their favor,
that kind of management "ethic" can thwart them [sigh]

Another is plain old diversity of scale (along multiple
"dimensions" at once). Its hard enough having to deal with
just one of: multiple releases, multiple customer bases/markets,
multiple customer/development sites, multiple variants,
multiple internal/external organizations. Having to deal with
two or more of those at once (and especially three or more)
can be the "straw" the broke the camels' back regarding being
able to manage the complexity with bare bones simplicity
and informality.

Each additional degree of complexity tends to require some
additional smattering of one or more of formality or ceremony
for docs, or communication, or additional artifacts.  2 or
3 of them at once can exceed the "thresh-hold" where its no
longer possible to be comparably "agile" like a modified XP
or SCRUM team, but simply hope to be as lean as feasible and
living with a lot more formality/artifacts than desired.

> I hope you'd try to do what I would try to do - use traceability
> to fix the immediate problems, and do what I could to
> increase the decoupling in the areas of code I touched.
> Also institute a general task to decouple legacy code
> until the problem was licked and the whole lot re-engineered
> or replaced (something I've only been given free rein to
> do once, to date).

I would certainly try. I've been in such a situation, and I did
try. Couldn't seem to get thru to my mgr nor my mgr's mgr. I
finally succeeded, but it took 1.5 yrs and much damage had
been done that could never be fully recovered from.

> > If developing incompetently includes "managing development
> > incompetently, I can buy that. If not, I have a proposed
> > addition to your list above :-)
> 
> Surely the bulk of the blame must lie with 'management'?
> Certainly it must in 'command and control' environments.

Methinks yes! :)
-- 
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
--^----------------------------------------------------------------