Extreme Programming is 6+ years old, and it's certainly been controversial. Many think it's impractical, unwarranted, or a wishful look at the way software should be developed. Others swear by it, or a related agile methodology. Others find themselves in the middle, and wish they could be on an XP team, or an agile team, or at least in a more agile group than they are now or were in several years ago.
Regardless of how you feel about XP, it has helped the industry because it has given us a goal and opened up a discussion on how to achieve it.
For example, take test-first development and refactoring. Test-first may be a controversial practice, but it has raised the profile of automated testing, which can improve code with or without any other XP practices. XP's love of constant refactoring may be hard to swallow, but it has brought a positive light onto rewriting nearly working code and replacing it with something better.
Today, I came across another example: pair programming.
At $WORK, I'm writing a parser for a rather complex and underspecified grammar in Haskell. This week, another wrinkle came up: the need to read and write Tcl-formatted strings. I'm sorta the research programmer on the team, so I'm pretty much on my own on this project. Which sucks, sometimes. For example, it's hard to bounce ideas off of a partner.
Again, XP gives us a model and a goal. With pair programming, one of the goals is to keep both a low level and a high level perspective in mind when writing code, rather than just one or the other. The model is to program in pairs, where one person focuses on the implementation details, and the other focuses on the larger level issues. Imagine my surprise when I started feeling some of the benefits of pair programming while programming solo.
Here's the trick: pairing $me[time()] with $me[time()+3600]. A couple of times today, I felt myself getting stuck on a problem without making any progress, I put it aside and pulled myself up to a higher level perspective. (Maybe that process took an hour, maybe less. I wasn't exactly keeping track of time. I'm sure some psychologist has an explaination on why and how you need to take time to switch perspectives.)
All of a sudden, my mistakes became clear, and it became obvious where I was hitting the wall. I couldn't see the way out exactly, but I could see the problem that was holding me back, and I got a vague feeling for where I needed to be. When I started diving back into the code, things gradually got clearer, until I hit the next wall. ;-)
I shouldn't have been surprised, but I was. There have always been times when I'm writing code where the best thing I can do is walk away from the keyboard. What did surprise me is that I found yet another instance where the best way to improve a non-XP process is to borrow a page from the XP book, ferret out the goal, and aim for it.
I don't really write my tests first, but I always do my best to have an automated testbench, that increases my confidence and allows me to refactor more freely, therefore being a productivity boon in general.
Pair programming is also great in improving output.
I used to hear grips that version control and software engineering practices were only useful on "large projects, or projects with more than one person," none of which were allegedly applicable to what we did here. However, I came up with the axiom that given enough time, any project appears large enough or appears to have more than one person. Come back to your code three months later, and it's like you're working with an older version of yourself.
