Beans per fortnight #Programming #extreme programming

I certainly can't accuse work of being boring lately. I'm hip-deep in the port to client/server, it's time for our semi-annual employee reviews (with the new addition of peer reviews), we're interviewing for software engineers and technical support people, and next week we start Extreme Programming for real (those of us who aren't in training sessions from Wednesday through Friday). It's been busy.

We made the XP decision early in January, per Don Roberts' recommendation. Things should get even more interesting over the next few weeks, as we blindly (well, mostly-blindly; Brian Marick will be coaching us next week) fumble our way into the realm of Extreme Programming.

We've been having some interesting XP discussions during this lead-up time. One such discussion was over working arrangements. XP requires pair programming, and most of our cubicles aren't really set up for two developers at one computer; and besides, Don Roberts suggested (and I think we'll probably do this, though not necessarily right away, since we don't have enough computers yet) that we set up a "bullpen" for our pair-programming, an area without internal walls, so everyone can hear what everyone else is doing and chip in at a moment's notice. We'd still have our own cubicles for filing and e-mail (as Kent Beck says, "people need privacy to take phone calls from their proctologist"), but any time we're doing something that will end up in the production code, we'd be pair-programming in the bullpen. This brings up discussions about bullpen logistics: phones (should we even have phones in the bullpen?), location, chairs, whiteboards, thermostats, lava lamps, and dozens of other things.

The most recent XP-inspired discussion was on what to call our abstract unit of work. I'll cheat here, by quoting the e-mail I sent to the rest of the department on the topic.

As we move into XP, we'll be changing the way we do time estimates. Instead of estimating in terms of hours or days, we'll estimate in terms of abstract units of work. And we need to come up with a name for those units.

So I'm announcing a contest: the Name-That-Abstract-Work-Unit Game. Get your suggestions to me by the end of the week, and we'll vote on them next week. The winner (dramatic pause) gets some free M&Ms from the dispenser! (applause)

Don Roberts suggested this idea of an abstract work unit. He called these units "beans" (and that's our working name for them for now, so if you don't like that name, send me your suggestions!). The idea is that, instead of saying "that's a day-and-a-half project", you say "that's a three-bean project". All that strictly means is that it takes about 50% longer than a two-bean project.

The main reason this is important is that we programmers really aren't very good at estimating time. Testing takes longer than we thought, design issues surface that we didn't think of, we need to refactor something so we can add unit tests, meetings take a chunk out of the day. Using abstract units will (this is the plan, at least) make those side issues magically go away — because at the end of each two-week iteration, we measure how many beans we actually got done, and that becomes our estimate for how many beans we think we can get done in the next iteration. Over time (and through the magic of statistics), the side issues start to get built into our estimates automatically.

It's self-correcting, in a way that hours-and-days estimates can't be. If I say something will take two days and it really takes three days, then I'm behind schedule. If I say something will take four beans and it really takes three days, then everything is fine, because we would know that four beans take (on average) three days to finish, and we would plan our releases accordingly.

I'm already running out of space on my whiteboard for the name suggestions. Figures that I was at home when I thought to blog about this, but I remember a few of them: quarks, parsecs, zots, joules, nuggets, ounces, rubles.

But my personal favorite so far has to be the banana.