Last night there was a very interesting extra meeting of the local AgileRTP group. Johanna Rothman was in town and Jared Richardson arranged an extra meeting so that she could present some of the issues which arise in adopting agile methods, and how to deal with them. Johanna is very knowledgeable and gave an interesting and thought provoking thought.

One of the issues she talked about was "distributed" agility. This is a hot button as many companies are outsourcing some development to "offshore" locations. Johanna talked about the issues in following agile practices, and I'm vastly oversimplifying here, pointed at time zones as the major issue.

Someone in the audience, who works in a distributed team with members across the US, questioned her on this. As the discussion unfolded, other issues came up, such as dealing with a team in China which had one person fluent enough in English who acted as the "email-translator", as well as cultural differences affecting communication.

Language and cultural differences certainly can inhibit the free exchange of information which is the coin of the realm in Agile practices, but I had to observe that these are not really geographical or time zone issues. I've seen similar difficulties with co-located teams.

Distributed development using agile methods can indeed work, I've seen it. OTI was quite good at it. We did timeboxed projects with development spread across the globe. A given project might comprise team members in Ottawa, Zurich, Sydney, Raleigh, and Vancouver. Large projects might use a "team of teams" but smaller ones had individual members who were geographically dispersed. There was lots of communication by phone and email, and it worked quite well.

OTI had one "stand-up" meeting every year, usually in February in the balmy clime of Quebec, an annual Tech Conference where everyone in the company got together at a sort of internal "OOPSLA" to talk about what they were doing and to exchange interesting ideas, and just get to know each other better.

Now the main thing that made this work was that we shared a common culture when it came to development. Although not everyone at OTI was a native English speaker, all were fluent.

"Big Dave" had a tendency to hire good people wherever he found them. Often such a person would seed a new multi-person laboratory, but sometimes a "lab" would be a single person.

So distributed development can work, and work well, given the right people.

Some agility advocates stress the need for co-location, a notable exception is Kent Beck, the founder of eXtreme Programming, who now spends most of his time based a his farm in southern Oregon, and does remote pair-programming using VNC and Skype, with programmers around the world.

And Kent is currently auctioning off a two-hour pairing session this is a good opportunity to sample distributed agility at a high level.

I wish I could afford to bid, the current bid is at $200, which is cheap. I've learned a lot every time I interacted with Kent personally in the past. Someone is going to get a deal, whatever the winning bid turns out to be.

Yesterday, David released RSpec 1.2.7, which includes a patch I provided to allow the specification of where to find the 'ruby' program when creating a SpecTask, rather than relying Rakes RUBY variable.

Why did I submit this patch you ask, assuming you didn't read the title of this post?

So you can do this in a Rakefile :

multiruby_path = `which multiruby`.chomp
if multiruby_path.length > 0 && Spec::Rake::SpecTask.instance_methods.include?("ruby_cmd")
  namespace :spec do
      desc "Run all specs with multiruby and ActiveSupport"
      Spec::Rake::SpecTask.new(:multi) do |t|
        t.spec_opts = ['--options', "spec/spec.opts"]
        t.spec_files = FileList['spec/**/*_spec.rb']
        t.ruby_cmd = multiruby_path
       end
   end
end

This is derived from something I just added to RiCal but haven't yet released.

What it does is check that you have multiruby, which is part of the zentest gem, installed, and that your version of RSpec supports the new ruby_cmd option. If both conditions are met it makes a spec task which runs the specs using multiruby instead of ruby.

Now it's easy to run specs with the various ruby versions you want to support.

A few days ago Corey Haines published an interview with his father about his father's programming career. Corey's dad, Terry, seems to be just a bit older than me and we started our programming careers about the same time.

This being Father's day, I hope you'll indulge me if I blog a bit about my dad, Joe DeNatale, who died just about 7 years ago.

My everyday mug

This mug goes into the dishwasher every night, and comes out every morning, it commemorates the J9 Java virtual machine from OTI. The logo is derived from the VisualAge logo.

A couple of weeks ago, the RailsEnvy podcast covered RiCal.

So I got the honor of joining the long list of Rubyists who have had the pronunciation of their names butchered by either Jason or Gregg. That's OK, I love both of you jokers.

On the podcast it's pronounced something like din a tal.

Yes, I've heard that one before, less commonly than dee natalie, and many other attempts.