Extreme ping-pong #Programming #extreme programming

Wow, I've been remiss in my blogging duties. We've been doing Extreme Programming for something like two weeks now (it's a little vague because most of us were in training classes for half a week in there), and I haven't blogged about it since before we started the first iteration.

So far, XP is pretty cool. It's always a challenge to explain the term to other people, though — people always think of extreme sports.

For those who aren't familiar with XP, I talked a little about it in my previous XP post. (We wound up going with "beans", by the way.) More info here and here.

Some of the daily comings and goings:

• We're nearing the end of our first iteration, and so far, we seem to have guessed our initial velocity pretty darned well (aside from one or two stories that we (that being me in at least one case) totally botched our estimates on).
• We've started having daily stand-up meetings, where we briefly say what we worked on yesterday, what we plan to work on today, and what (if anything) is holding us up (e.g., if we need to snag some people to discuss an issue, or if we'll need somebody to pair with later). We're following Brian Marick's advice, and charging people $1 if they're late (money goes to the Development Donut Fund; tax-deductible status is still being negotiated with the IRS).
• Most of our development now happens in the bullpen, which has phones now (but just two). No cubicle walls in the bullpen, just open space, so we can overhear each other and pitch in whenever we need to. The build PC and one of our test servers are in there too.
• The continuous build runs automatically (including the shorter-running unit tests) every time we check something new into VSS, and an e-mail goes out to all the people who just checked stuff in, telling them whether the build succeeded or failed. Longer tests are automatically run overnight. When we add new test units to VSS, they're automatically detected (via a naming convention) and included into the tests that get run by the build.
• All production coding is done as pair programming (two programmers at one computer).
• New code is written test-first whenever possible.
• Business decisions (what features we should work on, when we should work on them, how those features should behave) are made by people who understand the business needs (this person is called the "customer" in XP parlance), not by the developers. Once Development has put estimates on those features, it's also the customer that decides whether it's worth the time it would take, so the customer comes up with features and also makes the go/no-go decisions. This is good news for everybody, because we developers have never wanted to make all those business decisions, we're not good at it, but we've usually wound up doing it (and later getting blamed for deciding wrong) because there were no business people available to ask. With XP, we don't have to ask the business people — they tell us in the first place.
• Development decisions (how long the business requirements will take to implement) are made by developers, not by customers (and we're going to try hard to stick to this — when we say "it'll take twenty beans", they're not allowed to say, "you really meant to say eight beans, didn't you?"). We trust the customer to make the right business decisions. The customer, in turn, is expected to trust us (a little, at least, and more over time as we prove — hopefully — that XP actually does work better than what we've had in the past).
• XP has short iterations. In the Olden Days, people would spend two months writing specs, and then the programmers would all troop off into our cave for six months and write code. When we came back out, if what we wrote wasn't what the customer wanted, or if what the customer thought they wanted wasn't actually quite dead-on, it was usually too late to change the program if we still wanted to ship on time. But with XP, if the customer gives the wrong requirements, or if we misunderstand the requirements, the customer finds out quickly (within two weeks) and can fix it in the next iteration.
• We're planning an open house in the near future, to show off the bullpen (and to make sure people actually understand what the heck we're doing, especially the bit about them writing the specs, and them being responsible for deciding what does and doesn't go in the program).
• The lava lamps are, of course, on the way. (This is one of the things that's holding up the open house.)

Pair programming tends to be driving us toward more-standardized work hours; if I'm pairing with someone who gets in early and leaves early, then I need to get in early and leave early, because otherwise there'll be large chunks of time where I'm not allowed to do any production coding (or where I need to find someone else to pair with for a while). We started our iteration with semi-assigned pairs — these two people are working on this feature, these two are working on this — but it was only a matter of days before that started to become much more fluid, with people getting pulled in and moved around as needed (this person is in a meeting for the afternoon, this person's expertise is needed over here, so we'll juggle people around a little bit and keep going). This juggling is a really good thing, because it spreads the knowledge around even more, which improves our truck number. There tends to be some downtime here and there, when there are an odd number of programmers available and so somebody isn't pairing, but it gets spread around, so it's not the same person every time — and there's always research to be done, to fill in those gaps.

I haven't spent as much time in the bullpen this week as I did last week, because this week it's me and Sam on the rotation to be second-line client support, and we don't want to bug everyone in the bullpen every time we're answering a support call. So we got some help and spent an afternoon rearranging cubicle furniture, so we could code in a couple of our cubicles instead of the bullpen (those inside-corner desks are great for one programmer, but lousy when two people both need to see the monitors).

I've got two mice hooked to my PC right now (works great as long as they're both USB — don't even try it if one of them is PS/2), and hoping to get two keyboards in the near future (as soon as we can actually find two USB keyboards). I don't know how well it would work for each of us to have our own keyboard, but I really do want to give it a shot and see how it works.

We're not quite hard-core XP yet, because not all our development is test-driven (yet). But that's only because our current project is a major refactor of legacy code, which for the most part doesn't yet have unit tests (and, for the most part, isn't really designed in a way that lends itself to easy testing). We try to introduce tests when we can, and major new code is written test-first, but most of the time, there's really no good way to write unit tests for our changes. We'll get there, but it's slow going sometimes.

Yesterday my pair found a spot in the code where we could do some test-driven development, and he and I spent some time on something Brian Marick suggested to us, called "ping-pong programming": I wrote a test and made sure it failed, and then pass the keyboard over to my pair. He wrote the code to make the test pass, wrote another failing test, and passed the keyboard back to me. And so on. That was an interesting experience, especially as we tried to hold to the "simplest thing that could possibly work" doctrine ("no, you can't make that same change to the other branch of the 'if' — you don't have a failing test for that yet!"). The method we were writing was pretty trivial, really (take three parameters and format them into a human-readable string); I'll be interested to try ping-pong development on something tougher, later down the line.