> 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.
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...
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.
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.
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.
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...
> 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.
I'm certainly not saying that XP and open source are the same model, but rather that one thing they have in common is improved code quality ("given enough eyeballs..."). Are you aware that pretty much the only definitively reproduced finding in the literature about software engineering is that code reviews and inspections reduce bugs? The trouble is that if you do them after the fact, they're expensive. Prohibitively expensive, in fact, for commercial projects, so nobody does them. Plus they degenerate into boring pro forma meetings. XP's answer to this is rather elegant and if anybody knows a better one I'd sure like to hear it.
"Collective code ownership" sounds like everybody's going to be forced onto a collective farm and made to slave in the fields and then sent to barracks where they each get a potato for dinner and all go to bed at the same time, and the government raises your children. So I'm not surprised you think that it means your code will be seized by the state and you will never be allowed to "see a feature from inception to completion". Some of XP's terminology and dogmatism kind of foster these reactions. I don't like it either. But your objections don't really have anything to do with how stuff works in practice.
How like the software industry that we end up in a binary argument about whether "solitary" or "collective" programming is better. Just because we work with data that is either 0 or 1 doesn't mean that we have to be that way.
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.
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.