Virtues of Extreme Programming practices
Aside: I've changed the name of my blog to reflect a new writing approach. I've found, with good consistency, that being near-pathologically honest and forward is a boon to my learning productivity. Sometimes it causes temporary setbacks (embarrassment, remorse) when I step into areas that I don't fully understand, but the increased rate of progress is worthwhile. For example, this approach should help me get some SQRRR accomplished more readily, as I can get more ideas out in the open and don't need to feel like an expert on everything I write about.
In my limited experience with Extreme Programming (XP) practices, I've felt it was a long-term benefit for myself and my teammates. Unfortunately, because of XP's deviation from the more standard programming practices that I was taught, the activities originally carry a certain weirdness and unapproachability about them. Tests up front? Two people writing a single piece of code? Broadcasting the concrete tasks you accomplished on a daily basis?
After shaking off the inevitable willies, I've found that those activities improve relationships between myself and other team members and help to solidify code understanding and emphasize maintainability. From what I've read, this is what the developers of XP were trying to help optimize: the productivity that results from accepting the social aspect of coding. It is strictly more useful to form good working relationships with humans than with rubber ducks.
A nice secondary effect from the social coding activity is an increased flow of institutional knowledge. Everybody knows little secrets about the corners of your code base or have figured out optimized workflows — somewhat obviously, interpersonal flow of info helps keep more people in the know. When it takes five to ten minutes to explain a code concept to someone, both parties start to get the feeling it should be documented somewhere.
It reads a bit dramatic, but this snippet from the XP website has been fairly accurate in my experience:
Extreme Programming improves a software project in five essential ways; communication, simplicity, feedback, respect, and courage. Extreme Programmers constantly communicate with their customers and fellow programmers. They keep their design simple and clean.
The cons that I've witnessed are some minor bikeshedding and the increased overhead that seems to accompany these tasks:
Stand-up meetings take time from coding.
Unit tests take time away from "product code".
Pair programming has social transaction costs.
On the other hand, I've also witnessed these costs get amortized away:
Small amounts of bikeshedding can get the issue out in the open instead of letting it simmer in a passive-aggressive stew. Reasonable people seem to handle this just fine.
Telling other people on your team are what you're doing feels inclusive and keeps everybody in the know. (Plus, you can do it in twenty seconds per person once you've reached the steady state.)
Even a single, representative unit test forces some loosely coupled design-for-testability thinking and shows how you intend for the code to be used.
At Mozilla we seem to have a decent code review process down, which is one of my favorite social coding practices when it's done well. At the moment, my team doesn't seem too keen on some of the other practices I've found helpful, and it's certainly not something you should force. In any case, I'm happy to be the guy who talks about how great I've found these practices when the topic comes up until somebody comes around. ;-)