malvasia bianca

And now to some actual content from Agile Open California. As I mentioned before, I hosted a session called I Don’t Like Pair Programming, since the topic had been on my mind after our team meeting the previous week.

The title isn’t really accurate: I usually enjoy pair programming when I’m doing it, but my brain nonetheless persists in not looking forward to it. Which is weird—I would like to think that my brain is generally more sensible than that—so I thought I should ask for help understanding myself.

My guess is that it was the single most sparsely attended session at the conference: there were about five of us there. But I really enjoyed it, and am quite grateful to the others who showed up. The main piece of psychological advice that I picked up was contributed by Rob Myers (who learned it from the AYE Conference): it’s not that introverts don’t like people, it’s that we need time alone to recharge. Which suggests that, perhaps, if I had, say, one or two hour-and-a-half pairing sessions a day, I’d be more likely to enjoy (or less likely to feel trepidation towards) pair programming than I do in my team now, where a pair typically sticks together until either the day ends or the card ends. This would require other changes in the way my team operates, but I suspect they’re all to the good: we hog cards too much as is.

Steve Bockman also gave us the following pairing mechanics suggestion: pass the keyboard every time you write a test, get a test to pass, or refactor. Which sounds like fun to try; I don’t think that I’m bothered by keyboard hogging, but other people probably are, and I’m certainly curious what the experiment would feel like.

The other thing I wanted to talk about from the conference: for whatever reason, some discussion that we had during a session that Rob hosted on “Maintaining a Collegial Environment in a Competitive World” got me thinking about teams transitioning to agile. (No idea how the topic led to this thought; which is a sign of the strengths of the conference.) Some people (e.g. Ron Jeffries) strongly suggest that, if you’re intrigued by XP but aren’t sure it’s all a good idea, you should just do it by the book for a while, and see how it works. (As opposed to starting with the parts that make sense to you, and then maybe adding in more stuff and maybe not.)

But we can juxtapose this against two other ideas from the agile and lean worlds:

• When dealing with legacy code, there’s a temptation to just rip it out wholesale. But that’s a good idea much less often than you’d think: it’s often much better to accept the code and gradually refactor and add tests as you need to touch it.
• Taiichi Ohno has suggested (I believe, I’m too lazy to dig up a reference) that you shouldn’t start with a standard work specification that’s too good: it’s better to start quickly with something mediocre, among other reasons that it will be easy to find ways to improve it!

I’m not going to take either of these as suggesting that, in general, Ron is wrong: for one thing, sometimes the right thing to do with legacy code is to throw it out, and I’ve read stories from the lean world about Japanese experts coming in, making drastic changes, and getting immediate results. But what they do suggest is that, rather than focusing on getting the details of the situation right immediately, better to focus on how to improve the situation in a disciplined matter. In other words, refactoring supported by testing in the code world, continuous improvement via formal experiments in the process world.