Musings of a Software Development Manager

Jolt Award Winners 2006

Software Awards are funny things. At the Jolt awards these were the big soda can winners:

Quick thoughts are that Microsoft and Ruby cleaned up. I actually read the two books that won and I enjoyed both of them.

Behavior Driven Development

Today at SD West 2006 I took a hands-on session with Dave Astels on using rSpec. Dave’s primary message was we shouldn’t be talking about the word test in test driven development, but we should focus on behavior. Really when you’re doing TDD you’re specifying what the code should do not verifying that code works.

It’s an argument that seems to be picking up steam which is partly the idea of changing Test Driven Development to Test First Design or Test Driven Design. rSpec is essentially a replacement for xUnit in Ruby that focuses on nice English syntax for expectations in the form of:

should.have.at.least(5).items

I’ve seen something like this in Java as well with the JBehave project or Agiledox, but rSpec seems to be making some pretty nice progress. The exercise was to implement the game of Deflexion with a full set of expectations. It was a pretty well thought out exercise for a half-day tutorial and Dave was able to spend time wandering around answering questions effectively.

The surprising thing was I paired up with another developer who gets to do a lot of XP in his day job and we really marched our way through the tutorial. We managed to get through 24 tests, I mean expectations, in about 2.5 hours. Not that surprising unless you consider I’m a relative newbie to Ruby and he was a complete newbie, though probably a better pure coder. As a bonus I understand Ruby modules and their syntax a lot better now.

Anyway I’ll be working my way through the complete tutorial tonight, because Ruby and behavior-driven development is just a lot of fun.

Readable Code Through Domain Driven Design

I went to a hands-on tutorial today by Eric Evans on Domain Driven Design. It’s one of those less specifically technical areas that is harder to pull off, but Eric made a pretty good effort with about 30 of us.

Domain Driven Design as presented is primarily the search for a good domain model through a ubiquitous language. The end result is that writing the code should really expressive of the underlying domain. Something like:

billDate.month().end().plus(allowedWaitBeforePayment)

In English this easily translates to:

For the end of the month on the billing date add a certain number of days before payment is due.

It’s still Java so it has some syntactic noise that’s hard to avoid, but it is approaching more readable code.

Some key ideas:

  • A model not reflected in the code is irrelevant. (ie MDA)
  • UML should mostly be done messy on a whiteboard.
  • Try to verbalize the concepts you describe in a model to eliminate awkwardness.
  • Not a big fan of getter/setter.
  • Primitive data types are bad. (float for money)
  • Business people will not use your modeling tool.
  • It’s OK tho have multiple models in different contexts if they have clear boundaries.
  • Object reuse often hasn’t worked well because sharing objects across different contexts. A person object who’s an employee in your financial system doesn’t actually carry over to a person object in your CRM system.

The class was thought provoking enough to nudge me to pick up his book on Domain Driven Design.

RSpec Tutorial Out of Sync

Just setting up my iBook for the next two days of tutorials at Software Development West 2006 and I ran across a familiar problem. Dave Astels is running the hands on tutorial on Behavior-Driven Development and using RSpec which he wrote in Ruby.

My notes say:

Attendees should be able to run the RSpec examples successfully before the tutorial.

So I’ve downloaded RSpec 0.4 and tried to run through the tutorial. The very first example is write the following expectation:

1
1.should_equal 1

And I get the following error:

1
undefined method `should_equal' for 1:Fixnum

After much experimentation I tried:

1
1.should.equal 1

And I get:

Finished in 0.037051 seconds
0 specifications, 0 failures

So I wrapped it up into a little class:

require 'spec'
class ExpectationsTest < Spec::Context
  def expect_one
    1.should.equal 1
  end
end

Then I happily get:

Finished in 0.017554 seconds
1 specifications, 0 failures

I’m guessing the the tutorial hasn’t been updated to the current release of the software. Another minor thing is that when you do the install and confirm that RSpec works by issuing the

1
spec

command. You’re suppose to see:

Finished in 0.002726 seconds
0 specifications, 0 expectations, 0 failures

Instead I see:

Finished in 0.021852 seconds
0 specifications, 0 failures

Somehow the expectations total is missing which makes me wonder if I’ve done something wrong. Anyway I think I have everything and I should get a much better feel for it after the tutorial.

Update, turns out that Dave did mention the should_equal changing to should.equal in this blog entry. Now the tutorial just needs to be updated.

Story Points Estimating

I was skimming through Agile Estimating and Planning by Mike Cohn. I’ve used his idea of story points in the past versus using ideal days to estimate product backlog items.

Story points are just relative measures of the effort involved in estimating a user story. We write up use cases and not user stories, but the idea is generally the same since we’re often estimating the ‘happy path’ of a use case or one of the major alternative paths on our product backlog.

Ideal days are assuming you had uninterrupted time to work on a task and you had everything you needed at your fingertips how long would it take. It’s a little more concrete then story points, but the lingering issue is that ideal days assume a duration.

Mike uses an analogy about ordering at a new restaurant. Generally you don’t know any of the exact sizes of items. You can:

  • Order a small, regular, or super size drink.
  • Order cup or a bowl of soup.
  • Order the lunch version of the pasta or the regular entree.

None of these items gives you any exact measure of the size or even how many ounces are in the drink or how much larger or smaller the lunch version is. Still you can very easily order the right amount of food without knowing anything but relative sizes.

At the end of the day though I prefer the story points approach. Story points are a pure measure of effort.

Ideal days bring with them the baggage of time durations. Since things are measured in days there is always the temptation to think about them as durations and forget about the fact that they are supposed to be ideal days and not actual days. Observers to a project may find this to be the most troubling as they can easily get the mistaken idea that the team is underperforming given the number of days the project should get done in.

The other big downside of ideal days is that it potentially reinforces troubles developers have estimating already. Many developers are tilted towards optimistic estimates. My rule of thumb when a developer gives me an estimate is to simply double it, because they are thinking in their own semi-ideal days. After I know a developer better I tend to adjust, partially because there are a few other developers who estimate very pessimistically so that they aren’t ever in danger of missing a deadline. Anyway, keeping them thinking about days instead of ‘Adding an Approval Workflow’ is about twice or three times more work than ‘Maintaining Employees’ breaks the connection to time estimating.

By default right now we’re using ideal days to measure product backlog items. I’ve used story points on at least two past unofficial Scrum projects, and I’m going to experiment with it again on the second sprint for our intranet portal.

© 2025 Musings of a Software Development Manager.