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. ;-)
Tags: Extreme Programming, Peopleware, SQRRR
July 12th, 2010 at 09:31
[...] This post was mentioned on Twitter by Deb Richardson. Deb Richardson said: Chris Leary: Virtues of Extreme Programming practices: Aside: I’ve changed the name of my blog to reflect a new wr… http://bit.ly/bHi4s4 [...]
July 12th, 2010 at 09:59
“At the moment, my team doesn’t seem too keen on some of the other practices I’ve found helpful”
Elucidate.
July 12th, 2010 at 11:05
@Jeff Walden: That’s something we can take out-of-band.
July 12th, 2010 at 12:33
Works for me, although note I won’t be in the office again until the 26th, working remotely from Chicago area.
Also, to be clear, no antagonism was intended in my perhaps overly-terse query; I just hadn’t remembered any discussion which would seemingly fit the category, curious what I missed or what we weren’t warm to.
July 12th, 2010 at 16:11
Of the three aspects you mention (test-first, pairing, stand-up meetings), I think only pairing is the only really controversial one – it’s something very unintuitive, very theoretical-sounding, that assigning two people to collaborate on one task can be more effective than having them work on different tasks in parallel. It’s also a style that works for some people (I enjoy it), but which others find just doesn’t suit them, and nothing will change that for them.
Stand-up meetings, in contrast, are pretty easy to introduce. I don’t think I’ve ever seen anyone complaining that they waste coding time, because 1) people see the benefit of a quick catch-up each morning, and 2) they’re kept to just a few minutes and we tend to schedule them near down-time anyway, at the start of the day, or just before everyone would be going for a coffee break.
Finally, test-first. I think that’s actually the most important of the three. I find it takes a bit of a mind shift to start doing it, but once there, it’s entirely intuitive, and not at all controversial. I find it works particularly well for an exploratory approach – start with a test, and initially at least, implement the code *inside* the test. In such cases, I think of the test as a kind of incubator – somewhere where the code can be grown and matured until it’s ready for me to hook it up to the rest of the system…
July 20th, 2010 at 09:01
[...] "sanctity" of the retreat: chef-prepared meals, an indisputably good coffee machine, a Z80 prominently featured as a piece of wall art, and a complimentary bag-o-munchy-chips regimen. [...]