In the summer of 2009 I revisited my 2004 summer apprenticeship at Object Mentor. What follows is the original 2004 post and then some 2009 commentary.

Every time I think I understand FitNesse I’m wrong. After a day of using it for Acceptance Testing I know a lot more about it, but I’m going to assume there’s more. But this is jumping to the end, I’ll back up.

At the beginning of ‘XP for a Day’ Micah and James (the teachers) split the groups up and we started the planning game. James, the customer, had a bunch of stories written on 3X5 cards that he wanted implemented in the game. For example: One was a magic arrow that you could fire that would turn if it hit a wall (you specify the direction it will turn when you fire it). Another was a GUI for the game. And another was shooting regular arrows that would kill the Wumpus if they passed through the room he was in. Another was a randomly generated map. And so on. After James introduced the cards the time had come to assign numbers to them. This is one of the tricker parts for the first time XPer. The numbers are unit-less and do not correspond to a set amount of time. But the are a measure of how much time the task will take. Huh? Lemme ‘splain: Take all the cards and arrange them from easy to hard. Some are the same level so they will be a pile of easy, a pile of hard and a few piles in between. Now let’s call the features in the easy pile ones. What does one means? It doesn’t. But now we have a reference. All the other cards are defined in terms of the easiest ones. Is this task two times more difficult or three times more difficult than the simple ones? Unfortunately, since most programmers have a background of spending lots of time on design we spent too much time arguing over the points on each card. But it was a good learning experience. Then we guessed how many point we thought we could do in one iteration (1.5 hours in this mini-XP version). My group had no idea, but everybody else said 4 and we went along with the crowd. How many did we finish? 1 point. And here’s where I take a bit of issue with the class. Learning FitNesse is a day in and of itself. None of us were that familiar with it (I had used it in the TDD class I took, but some problems still were beyond me) and so we spent most of our iteration trying to figure out how to get the acceptance tests to work. Leaving precious little time to code.

Which is everybody’s biggest fear about TDD – that the test will slow you down. And I think one iteration will always be sacrificed to figuring out FitNesse or Junit (which we used too, but most were familiar with it) or whatever. The second iteration went much better. Now that we knew how to set up fixtures and get them to work, we were able to hit our target velocity much better. My personal feeling is that this needed to be two days if FitNesse will be new to most of the student (as I suspect it will be). If it has to be one day, then maybe unit test will have to be enough. Regardless, I learned a bunch and felt the class was a qualified success.

The problem with having students work on real things is that often they get hung up on something that shouldn’t be the focus of the class. I had this one week long physics project where the students would plan how to launch a spaceship and have it reach Mars. The first step is drawing a scale model of the solar system out to Mars. Most of the kids spent the better part of the first day just trying to figure out a scale so you can fit all the orbits on the paper. I had foolishly assumed that such a task would take a few minutes because it was easy for me.