xml-dev - RE: Extreme Programming goes mainstream?

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Pair-based programming is probably better than 
the notion that having lots of eyes look at code 
improves it and everyone seems to accept that one. 
That they should both be on the same machine seems 
both awkward and unnecessary.  The problem here 
is picking the right pair and making sure that 
they have and will use complementary skills.  The 
problems of the "insular coder, the lone hacker, 
the hero programmer" etc are well known and have 
caused many a business model driven project to 
fail.  The other extreme of that are the 
secrecy obsessed organizations that breed 
personal competition into every level of their 
employees with carrot and stick management. 
 
This makes XP almost impossible to implement 
in the development groups and leads to the 
very common inter department schisms between 
the business types (the suits) and the 
artistics (the programmers).  We are watching 
some well-established firms dropped to their 
knees in their stock prices as the market 
observing a lack of innovation and the failure 
to deliver on promises made lose confidence 
and simply ignore these companies.  This is not 
just a dot.com problem; it is epidemic in the 
computer science industries particularly where 
the CEOs and CTOs have yet to understand that 
the Internet business is not about building 
a barrier of complexity to competitors; it is 
about building simple strong bridges to allies.

You have to pick a model for interaction that 
scales up the levels of the organization.  You 
can't depend on a power elite; you must depend 
on a process that self-validates and self-organizes. 
In a sense, these organizations work much the 
same way an XSLT stylesheet works; it tries 
as much as possible to remove a dependency on 
globals and relies on smart recognition of 
patterns.  That is why the pairing must be 
precise; what each one recognizes as they 
work together is vital.  It isn't a pissing 
contest; it is a game of styling.

The problem is control, how to get it, 
keep it, and use it wisely to ensure your 
company is profitable and employees 
are satisfied.   Unless you can do this, 
the business plans will not be met and 
no amount of cajoling or browbeating will 
change that downward slide.  Our business 
depends both on application and innovation 
and knowing when to do which of these for 
some given project.  Whatever else you do, 
you must train fear out of the employees 
and yourself.  Knowledge and a certainty that 
what is learned will be applied sensibly leads 
to confidence.  XP, done well, leads to confidence 
in the code and the product, thus the management 
must be the styler of confidence, it cannot 
be simply, confidential.

"The problem is not in the stars..."

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Tim Bray [mailto:tbray@textuality.com]

Maybe, 20 years after I got into this profession, we can
finally leave behind the notion that the business people 
will write a complete spec for what they need, and the 
programmers go implement that.  It's never worked outside
of a few specialized domains, and never will.