Lists Home |
Date Index |
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Tim Bray <firstname.lastname@example.org>, David Megginson <email@example.com>,firstname.lastname@example.org
- Date: Fri, 15 Dec 2000 08:24:23 -0600
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..."
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Tim Bray [mailto:email@example.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.