This delightful summary of Extreme Programming goes a long way toward explaining why it is so attractive to a certain managerial personality type.

• Integration is a nightmare, so integrate continuously
• Writing tests is tedious, so write them first
• Social interaction for developers is often difficult, so pair all the time
• If it ain’t broke don’t fix it, so refactor mercilessly

It has Purtian over tones; e.g. that what every your staff is doing it’s very likely selfish and they are ignoring the real work.

Framing things up in that manner is good fun until sombody gets a stick in their eye. Easy to wound your enterprise by taking those rules too much to heart. For me framing the principles of extreme programming is dangerous. It councils that you ought not play to the strengths of your talent. You should strives to supress them. That’s unlikely to either attract talent or build momenteum.

• integrate continiously assures you take only small steps
• writing tests first assumes the code and platform has nothing to say about the problem
• pairing programmers assures you leave a large swath of good talent for your competors to hire
• refactor mercilessly assumes you have large code bases rather large installed bases, poor you.

That said, all the above are true to a surprising degree. In fact these same four have mimics in open source. For example we don’t pair program but we know that situating the work in a highly public way is effective both for social, inspection, and testing reasons.

Refactoring, though, is a challenge in open source because we are more typically entangled in a larger more vocal installed base. The often lower and more difuse code ownership also creates a web of entanglement (a social web) that makes refactoring a more costly exercise. In extreme programming the test suite substitutes for having a live installed bases; so there the immovable installed base problem is replaced by the immovable test suite. The good news for open source is that the public process can increase the number of voices advocating a serious refactoring.

It’s worth noting that encouraging refactoring runs counter to the advice to integrate continously. Refactoring is fundimentally a choice to buy a bag of disintegration. So the pair of them is a cruel catch 22. For open source: developers can operate in private and they can fork we do license these kinds of disintegration moments. Though we probably don’t encourage enough of them and we lack rituals from bringing them home.

I’ve got to thinking recently that there are times in the life of an open source project were the community would be wise to encourage forking in search of a way out of the box of their current architecture.