My Apprenticeship - Sunday, August 15, 2004

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Sunday 8-15-04

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.

Comments

Post a Comment

Popular posts from this blog

What's a Good Flog Score?

I've been using Flog to measure the complexity of my Ruby code and I was wondering how others interpret Flog numbers. I'll go first with my opinions: Score of Means 0-10 Awesome 11-20 Good enough 21-40 Might need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children (note: these are scores for an individual method) The 20 - 60 range is interesting to me. Sometimes the complexity of what you're doing will justify the score and other times the method is in desperate need of refactoring. The highest Flog score I've seen in the wild was in the 300's. What's you're personal high and what do you think of my rankings? In other news, I've redesigned the look of my blog so if you only see my post through a reader you might want to stop on by, take a look, and tell me what you think.
Read more

SICP Wasn’t Written for You

The number of software luminaries who sing the praises of “ Structure and Interpretation of Computer Programs ” (referred to as SICP) is such a long list that you might think only a crazy person would take issue with it. However, to ignore SICP’s problems and continue to blindly recommend it seems just as crazy. SICP was the textbook for MIT’s introductory programming class and was a bit of a departure from other into to computer science textbooks at the time.  Wikipedia sums it up nicely:  “Before SICP, the introductory courses were almost always filled with learning the details of some programming language, while SICP focuses on finding general patterns from specific problems and building software tools that embody each pattern.”  Which sounds awesome, but does essentially say that abstract principles will be introduced before the nuts and bolts of a language.  If you think about that for a minute, you may see where the problems will be. When I was training to be a...
Read more

Point Inside a Polygon in Ruby

Recently my team needed to find out if a point was inside a given polygon and, as usual, we found some code on the internet that did what we wanted. And, as usual, there wasn't much explanation as to what it was doing. Here's the code (after we converted it to Ruby): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def contains_point? (point) c = false i = -1 j = self .size - 1 while (i += 1 ) < self .size if (( self [i].y <= point.y && point.y < self [j].y) || ( self [j].y <= point.y && point.y < self [i].y)) if (point.x < ( self [j].x - self [i].x) * (point.y - self [i].y) / ( self [j].y - self [i].y) + self [i].x) c = !c end end j = i end return c end end So, you know, it works and I'm grateful to somebody for posting it but we had no idea how it works. So we wrapped 2 tests around it (one where the point is not in the polygon and another where it is...
Read more