

Extreme Programming Explained - ivank
http://www.yosefk.com/blog/extreme-programming-explained.html

======
wallflower
> The permanent brain damage of that CMM training course makes me admire XP.

OK. This article espouses XP as a religion. What irritates me is that implies
an all-or-nothing approach of XP. You want floormats with that car? Pair
programming with iterations etc. Which can be too much to handle - just
adopting some of the XP principles and practices can make a big difference -
stand-up meetings for example. I worked on a project that just started having
stand-up meetings - to replace the once-weekly meeting where we would all
either just fume at each other or silently say nothing. Communication improved
to a point where we realized there was _no_ real communication going on before
(e.g. this is how I _feel_ with X task)

That being said. Is Agile better? I don't know. I'm working on an Agile
project right now - I hate the burndowns, hate them with a passion - reducing
your accountability to a number. But what it does - updating burndowns is it
makes your progress transparent - to you as well as the other people on the
team.

~~~
timcederman
Haha, as a PM I've found engineers hate burndowns with an absolute passion.
And so do I. But you're right - the transparency makes it worth it. I try to
make sure I gather the data in an unobtrusive manner as possible, and keep
irritating meetings to a minimum. No matter what I do it still gives people
the irrits. Having worked as a software engineer, I wish some of them would
work as a PM for a bit to know what we go through as well...

------
noonespecial
XP is a specialized tool for getting specialized results. As the article
mentioned, it is good for getting large volumes of average code. (And likely
doing so with fewer mistakes).

We XP for the same reason we have 2 pilots on an airliner. Its long and boring
but messing up can be very bad. So we send 2 people to manage the drudgery,
keep each other motivated and catch mistakes that could lead to problems
later.

The virtue of the lone expert however, applies to a very different type of
problem. He has to be free to try the most wild outlandish things that pop
into his head. This is not possible in a "pair programming" environment. There
is astonishingly little difference between design flaw and brilliant
innovation in this space.

When we test the X-1 we send Chuck Yeager not a pair of pilots from Delta.

------
gaius
He hits the nail on the head with this article - XP is a methodology for large
groups of average programmers to write large volumes of average code. This is
not necessarily a bad thing; that is the requirement of most large
organizations. Most corporate software is just forms and reports in front of a
database; there's nothing _algorithmic_ in there that necessitates deep
concentration. It doesn't matter how big the codebase is. That's why XP
doesn't care about ownership of code, or the "social" aspects breaking
concentration.

But XP is simply not suitable for real "extreme programming", i.e. small teams
producing novel products. There is a BIG difference between "specs that change
because a business user can't make up their mind" and "specs that change
because we are writing a program that has never been written before" which
completely escapes XP people.

~~~
gruseom
I'm no XP fan, but this comment is ignorant. It's entirely possible for two
people to concentrate together on a hard problem, and when it works well you
get a "two heads are better than one" effect. It matters a lot how big the
codebase is on _any_ software project (and XP is well aware of this).
Collective code ownership is advocated for a number of good reasons, such as
that it mitigates risk and increases quality (think open source). The vast
majority of "large groups of average programmers" are not doing XP and would
hate the idea of it just as much as you do, and for some of the same reasons.
Plenty of XP projects have above-average programmers. (Edit: Oh, and by the
way, when I was paying attention to this stuff the corporate types were the
source of greatest _resistance_ to XP, while most of the people advocating it
were technical. So it's a little rich to hear XP described as a corporate
conspiracy to impose a drone state on creative programmers. Perhaps it's
changed since then.)

XP provokes a lot of one-sided emotional reactions from people, some in favor,
most against. (I'd include the OP in this.) In fact, I've noticed that some of
the most cultish XP people turn out to have been the ones who had knee-jerk
negative reactions at first. Once they decide they don't want to sit in a room
by themselves all day after all they flip one bit to the other and become
evangelists of the opposite. The irony is that much of what they say both pre-
and post-koolaid is actually true. But it gets spoiled by rigidity.

~~~
gaius
But you don't need compulsory socialization to do that! All you need is a
colleagues who you talk to from time to time. What if the person who knows
exactly how to do what you want to do is someone elses XP buddy? Now you have
two people stalled instead of just one.

There is ample evidence that "ownership" of code results in better quality and
a more motivated workforce. People like seeing a feature from inception to
completion. So long as basic conventions are adhered to, there's no need for
anyone to touch anyone elses code except in a genuine emergency.

Can you point to any open source project that is actually collectively owned?
I think not, everything actually has an owner who gets to say who gets to
commit what...

~~~
wallflower
> Can you point to any open source project that is actually collectively
> owned?

Collective ownership - maybe more like republican ownership - see the
code_swarm videos - only a cluster of people commit.

Successful open source projects are led by very strong leaders: (Linux)
Torvalds, (Ruby on Rails) DHH, (Gnome/Mono) De Icaza. Eclipse is questionable
- it's more like run by a board of directors, with a large (mostly IBM)
programmer workforce.

> But you don't need compulsory socialization to do that!

Agreed. We got past the teamwork learning curve and we pair when we have to
get things done fast/fix a problem. We usually don't pair otherwise, unless
you count long-running IM conversation threads as pairing.

> XP provokes a lot of one-sided emotional reactions from people, some in
> favor, most against.

As for emotional reaction, I still get a heebie-jeebie hokey feeling when
someone says "I'll drive" [but only in reference to pair programming].

As an aside, pair programming does not work in a dom-sub relationship
(especially when the sub is passive and doesn't want to code) - the dom will
take over the coding.

------
gruseom
XP does have a social bias. Eric Evans once suggested "social programming" as
a more accurate name for it. When combined with the formulaic nature of
software "process" (do these 12 things, code must be written in pairs, etc.)
this aspect can turn weird or even cultlike. That's unfortunate because the
best and most fun software projects are indeed (in my experience) highly
collaborative. But compulsory socialization isn't fun at all.

------
timcederman
As much as XP has its flaws, I don't think it deserved the smackdown it got in
this article, which was somewhat biased.

Also what was with the bizarre, idiomatic, confrontational writing style?

~~~
gaius
You've not read a personal blog before then?

