Re: Digest Number 132

Ron Jeffries wrote:

> On Friday, January 9, 2004, at 7:23:26 AM, Jorge Diz wrote:
>
> > I don't agree with the "don't tell them" approach, by principle:
> > I think the project management/customer relationship/culture
> > issues are the main ones driving XP acceptance (or lack of), and
> > the challenge is to get a common understanding of the dynamics in
> > SW development.
>
> Yes, I agree here. I think we need to find /ways/ to tell the truth to
> everyone concerned. The standard XP "talking to programmers" style is
> probably not the way to get managers on your side. But there are ways of
> talking to them that can work. Bill Walton has some really good ideas
about
> that, I believe ...

High praise, indeed.  Thank you, Ron.

I agree with Jorge completely and have, for the past many months, been
trying to understand what they (and I) aren't "getting."  I've come up with
a couple of hypotheses and have started writing again.  My first hypothesis
is that the root of the problem lies in confusion, caused by the words that
have been histsorically used to describe software development activities,
over the *nature* of software development.  So my first tack will be to try
to clear that up.  I'll be doing a series of columns for Computerworld.com,
the first of which appears in the IT Management section on Monday.

At the risk of giving away the punch line, the argument goes like this:
1)  Software development (i.e., the creation of working software) is
*entirely* a Design/Development phase activity (phase being used in the
Product life cycle, not Project life cycle sense)
2)  All Design/Development phase activities,  independent of domain (e.g.,
computer hardware, office buildings, etc.) are best managed using an
Iterative, Incremental approach because the single most important determiner
of success in Design/Development efforts is feedback.
3)  Feedback needed is a function of the amount and types of Innovation
(including such markers for Innovation as Uncertainty and Complexity)
embodied in the project.
4) Software development projects typically involve large amounts of
Innovation of various types and thus need large amounts of high-quality
feedback.
5)  Feedback allowed is a function of cost constraints (time and money).
6)  The nature of software (i.e. the fact that 'fabrication' consists of
compiling/linking) reduces the cost constraints associated with producing
product on which to get feedback to improve the product, thus allowing
software development efforts to take an even *more* iterative, incremental,
approach than is typically allowed for hardware development efforts.

Once the reader accepts that line of argument, the only question left is
"What's the best approach for minimizing the time-to-feedback loop?" and I
think the answer to that is pretty obviously XP.

The first column deals entirely with number 1 above.  My feeling is that we
(PMs and managers in particular, but lots of developers too) have fallen
into a linguistic trap that leads us to believe that a major portion of
software development is something other than a Design activity.  I know that
was true for me.  Then I realized it wasn't true; that a programmer writing
code is doing Design just as surely as a EE using a schematic capture tool.
So I used the first column to try to deal with that.  I think the rest of
the assertions above are fairly non-controversial and will be easily
accepted if I can make a convincing case for #1.

Anyway, I'd be honored to have your feedback.  The article is at
http://www.computerworld.com/developmenttopics/development/story/0,10801,880
90,00.html

Best regards,
Bill


 

Yahoo! Groups Links

To visit your group on the web, go to:
 http://groups.yahoo.com/group/xpAdoption/

To unsubscribe from this group, send an email to:
 [email protected]

Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/