What must not be spoken of

You join a new project (and if you’re a consultant like me then this happens a lot) and you start asking a bunch of questions. Where’s the svn repository? What version of Rails are we using? How do I install this other thing upon which our thing depends? And the answers come. But then it’s a few days later and the more sensitive questions come: Why aren’t we pairing much? Why is this meeting scheduled to take most of the day (when it should 45 minutes at most)? How come the dev boxes are so slow? And if the answers you get to those questions are variations on “Um… We can’t do that – talk to me about it later.” then something is busted.

You don't know what it is, but you can feel it in the atmosphere. It’s tense. Some things are unspoken and mysterious forces are making sure it stays that way. Every iteration seems like it has too much in it. Its common knowledge that we have way more scheduled for release 1.0 then we can do in the time allowed.

If this is how XP feels then you’re doing it wrong. The point of an iteration isn’t to make every week a death march, it’s to increase visibility. If you didn’t get your 20 points of work done this week, the solution is not to mandate overtime or give speeches about how we “really need to get more done this week” and you certainly don’t want to just sign up for another 20 points for next week (only to fail again). If 2/5s of you team was out last week or lightning struck the servers then you can call it a bad week and move on. What bugs me is when people get pulled out for normal things (meetings, other projects they are assigned to, or normal fire dousing) and then the “bad iteration” gets blamed on “circumstance beyond our control” and we sign up for the same amount of work. There will, believe it or not, be more meetings in the future. So just call it overhead and adjust the amount of work we can accomplish in a week. And if that means we won’t hit our release date, then its good we know now. Right? If its not good we know now, then we’ve got a whole other set of problems.

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