I’m headed off to Seattle this week for some certified ScrumMaster training with Ken Schwaber. I should be able to glean a lot of ideas off the fellow participants experiences as well as Ken’s. One of my biggest questions is how to go about integrating Scrum when many of the projects we work on are small from a developer perspective, typically just two developers.

Came across a minor oversight in a Ruby example on pg 49 of Programming Ruby. The test code checks that you can find a song in a list which is just wrapped into an array of song objects. It worked find until I used a negative test case to search for a song title that shouldn’t be in the list.

def testFindBySongTitle
    assert_equal(@song1, @song_list.with_title("Love Song"))
    assert_nil(@song_list.with_title("love song"))
  end

I got the familiar red bar and an error

. So I stared at the code for a bit looking for something funky:

class SongList
  def with_title(title)
    for i in 0..@songs.length
      return @songs[i] if title == @songs[i].name
    end
    return nil 
  end
end

As it turned out I noticed it was actually iterating over the length of the array and since Ruby arrays are zero based indexes, I really needed to add the familiar

.

class SongList
  def with_title(title)
    for i in 0..@songs.length - 1
      return @songs[i] if title == @songs[i].name
    end
    return nil 
  end
end

So once again a negative test case came in handy. I went ahead and submitted it as possible errata.

I came across Ruby Conventions for Java Programmers a while back, but still fairly helpful. Every language has its own idioms.

Joel Spolsky argues recently somewhat tongue in cheek that Java just isn’t a good language to differentiate potential programmer candidates. At a high level I can agree with the sentiment that you want to know that someone knows more than Java.

On the idea of weeding people out I can’t say that his focus on understanding the ins and outs of pointers makes a whole heck of a lot of sense. Doing my undergrad at Georgia Tech in Physics many years ago my weed out courses were Differential Equations and Thermodynamics as I remember. I remember a time honored tradition at Tech was explaining to the incoming freshmen:

Look to your right, now look to your left. By the time you graduate neither of those people will be there.

I remember thinking at the time that they were exaggerating. By the time I graduated 4 years later I realized they weren’t.

Still with most candidates I look at the college they graduated from is a single line on the resume. Much more important is what they’ve actually done and whether they can actually describe it. A really great candidate would have a blog they could point me at and maybe an open source project or two that they had contributed to. I’m not sure that having them explain pointers means much to me, but I do typically ask a question about which language they’d prefer to use and why?

I have a defacto rule I try to follow with resource allocation. For any project beyond simple maintenance I always assign 2+ developers. The reasons are fairly obvious:

• At least two developers know the source code.
• Each developer is able to bounce ideas off the other one and help work through roadblocks.
• It’s hard to develop tech leads if most people work on solo developer projects.
• It allows each developer to typically work on more projects per year, lessening the chance that the only project they work on ends up being cancelled.
• If a single developer goes on a 3 week vacation the project grinds to a halt.
• I don’t have a lot of developers who own certain software products and are then over utilized for any enhancement requests. Example, one of our products typically has at least one major enhancement per year. We have one developer who really knows this product and so whenever the business decides to add an enhancement we lose his talents for a few months, often in the middle of another project.
• And lastly, “The bogeyman hates the buddy system.” Or spreading your risk is almost always a good thing.