XP Day 2008: Debugging Pair Programming

At XP Day 2008 I proposed an open-space session on pair programming. Specifically, I wanted to explore the reasons why programmers might not want to pair, or find it such an unpleasant experience that they’re put off doing it again.

Judging by the great number of people who turned up and stayed for the session, it’s clear I’m not the only one who is struggling with these issues, adding more weight to my suspicion that pair programming is the hardest of all the XP practices to master.

I worked with Laura Plonka to devise and run the session. Laura is researching her PhD thesis on pair programming, using video footage to analyse pair programming sessions, then running a retrospective where the pair get to debrief and share their experiences of the session.

Despite the huge contribution from everyone present, at the end of the hour, I felt as though we had only started to scratch the surface of the problems we’d identified. It seems as though too many teams, even at organisations who are ostensibly keen to embrace ‘agile values’, suffer from some toxic cocktail on this menu of dysfunction:

  • an agile-zealous leadership which forces people into unwilling or poorly-chosen pairs
  • a culture that, at some level, values heroics over craftsmanship, such that programmers may feel a subtle or unconscious reluctance to chose to pair on a task unless it looks utterly daunting, and there could be no shame in being seen to ‘ask for help’.
  • a team that disagrees on the types of tasks that should be done as a pair
  • team members who are far enough along the autistic spectrum (as Joseph Pelrine and Ben Fuchs pointed out, we have a higher proportion of these than many other professions) that they find the level of inter-personal communication required for pairing difficult or impossible.
  • ‘Experts’ on the team who feel that pairing with less experienced members of the team will slow them down too much
  • ‘Newbies’ on the team who are afraid to ask for help, or feel the work they’re doing is too mundane to need to be done in a pair

There were masses more issues brought up – these are just the main few that I can remember now. Hopefully more people will write up their sections on the session’s page on the XP Day wiki, or maybe comment on this blog post.

I spent the latter half of the session in a small group discussion the influence management can have on the adoption and enjoyment of pair programming. Paul Field and I enumerated the benefits that teams who embrace pair programming and create a culture where it works, can enjoy:

  • Better system knowledge across the team (higher truck number)
  • Skills transfer between team members (free training)
  • Team bonding
  • More defects found & found earlier
  • Better solutions/designs
  • More fun (better staff retention & morale)
  • Better focus (less time wasted in email / facebook)

It’s worth holding onto this list, and thinking about it when experimenting with pair programming within your team. Not all these benefits will be immediately apparent, so it’s worth being patient and trying to figure out ways to measure them to give you feedback as to the success of your experiment.

Another great idea I heard for teams that want to try pairing but are unsure as to which tasks are appropriate: try doing every task in a pair for at least five minutes. If, after that time you both agree that it’s a waste of time to do it as a pair, you can split up.

I still feel like there’s huge amount of work to be done to collect and disseminate the patterns and anti-patterns around pair programming, but I’m glad to have at least stirred up the pot a little. Thanks to everyone who turned up and contributed so much, and thanks especially to Joseph and Ben for organising a follow-up session later in the day where we had the opportunity to drill down into those psychological barriers a little bit more. Great stuff.

In Defence of class << self

I recently came across this blog post from the venerable Chris Wanstrath (of github / err the blog fame) which took me somewhat aback. Chris suggests that using class << self to contain class methods (C# / Java programmers read ‘static methods’) is a harmful habit that should be discouraged.

I dislike class methods generally: they remind me of procedural programming, and can be awkward to test. Yet I actually rather like this ruby idiom and I believe that there are some very good reasons to use it especially when refactoring.

Disadvantages

Following a thorough discussion of the advantages and disadvantages on the RSpec mailing list, I can tell you the reasons why you would not want to use it:

  • It can cause confusion for programmers who are inexperienced, or new to Ruby, who find the unfamiliar syntax and concepts hard to understand.
  • It can cause confusion for any programmer when working on a class file so long that the class definition has scrolled off the top of the screen, so you can’t tell if you’re looking at an instance method or a class method.
  • Your code will run (a bit) slower.
  • Some people might think you’re being overly-clever and showing off. As Mark Wilden puts it:

> look at me, ma, I’m opening the eigenclass!

Advantages

Here is a summary of the reasons why you might:

  • You can do things like make certain class methods private, and define attribute accessors for instance variables of the eigenclass.
  • You might think it looks cleaner.
  • It can help you to think in an object-oriented way about the class methods you’re defining.
  • You might find it aids refactoring.

My Take

In the end, I thought Brian Takita summed it all up very well, after some verbal jousting with Mark Wilden:

> I’m wondering if this is a discussion about taste. I have my
> experience with both approaches and you have yours. Just because
> something works better for you does not mean its going to work better
> for me and vice versa. I know that using class << self has been very
> helpful in making my design better and it helps me to understand the
> code vs the def self.method_name.
>
> I see def self.method_name as a useful shortcut in irb or when there
> are few (0 to many depending on the person and situation) simple
> methods on the class. There is a point to where it, IMO, makes the
> code more difficult to understand, though.

So it’s a pretty subtle and subjective thing, and perhaps less risky in a situation where all the people working on the code have a feeling for what makes a good design.

When reading code, I’m generally doing some basic warm-up refactorings to get used to the code, and one of the first things I want to do is group up all the class methods which are often sprinkled around the file together, clearing away the clutter so I can see the instance methods that define the actual behaviour of the class.

At this point, class << self is only marginally useful. I can quite easily group all the class methods just by putting them at the top or bottom of the file. Using a class << self block would allow me to fold them closed in Textmate, but that’s not really all that important to me.

Now let’s imagine that one of these private methods is long and ugly.

As I start to extract smaller methods, I want to be able to mark them as private so it’s clear that they’re not part of the public interface of the class.

This is the point where class << self starts to add value. It’s a safe and painless step to move the methods inside a class << self block, remove the ‘self.’ prefix from the method definitions. Now I’m in a position where I can extract smaller private methods from the class methods.

Often, as I do this, I start to see responsibilities in the eigenclass methods that could belong together in another class. Factories often start as a class method, for example. As soon as it becomes clear that a break needs to be made, it’s easy to move the methods into the newborn class. This refactoring can be gently introduced by delegating to the new class from within the eigenclass.

Refactoring Example

Imagine that we have a model where Dogs are born with a temperament (playful, angry, etc.) that cannot be trained out of them during their lifetime:

class Dog
 attr_reader :temperament
 def initialize(temperament)
 @temperament = temperament
 end
 end

Now suppose we want to limit those temperaments to just a couple. A valid way to do this might be to create a few factory methods, and mark the initializer method as private:

class Dog
   attr_reader :temperament
   def self.new_happy
     new(:happy)
   end
   def self.new_angry
     new(:angry)
   end
   private
   def initialize(temperament)
     @temperament = temperament
   end
 end

Although the current example is trivial, I’m going to refactor those class methods inside an eigenclass block, just so you can see what it looks like:

class Dog
   attr_reader :temperament
   class << self
     def new_happy
       new(:happy)
     end
     def new_angry
       new(:angry)
     end
   end
   private
   def initialize(temperament)
     @temperament = temperament
   end
 end

Same code, different convention. Whatever.

Now suppose we get a requirement that all Dogs must have an owner. It has do be defined when the Dog is born. Now we’re going to have to take the owner as a parameter on all those factory methods:

class Dog
   attr_reader :temperament, :owner
   class << self
     def new_happy(owner)
       new(:happy, owner)
     end
     def new_angry(owner)
       new(:angry, owner)
     end
   end
   private
   def initialize(temperament, owner)
     @temperament, @owner = temperament, owner
   end
 end

How boring. Now obviously this is a silly and simplistic example, but with something in the real world, we can imagine a situation where the evidence for factoring out a DogFactory would start to weigh up. Here we go:

class DogFactory
   def initialize(owner)
     @owner = owner
   end
   def new_happy
     Dog.new(:happy, owner)
   end
   def new_angry
     Dog.new(:angry, owner)
   end
   private
   def owner
     @owner
   end
 end

So you can see that our shiny new DogFactory looks a lot like the eigenclass that was hiding inside of the Dog back there.

And what does our Dog class look like now?

class Dog
   attr_reader :temperament, :owner
   private
   def initialize(temperament, owner)
     @temperament, @owner = temperament, owner
   end
 end

Nice and tidy. If we need to support clients who are used to the old factory methods on Dog, we can do it like this:

class Dog
  def self.new_happy(owner)
  warn("Please use a DogFactory for creating Dogs.")
end

Note that I deliberately used ‘self.’ here to define the method. To me, the refactoring is now complete and this deprecated method is starting to wither away and die, and so it’s OK if it takes an evolutionary step backwards again. Right now I don’t really care whether it’s defined in a class << self block or not.

Wow. If you’re still with me, I hope that gives you an insight into how I think this technique can help you to clean up your Ruby code.

I probably spend at least as much of my time refactoring other people’s code as I do writing new code, so that may affect my perspective on this. Time after time when refactoring, I’ve seen methods move from instance methods on a class, to class methods, then finally off onto a shiny new (testable) class as instance methods. I think that anything that helps you to see the new class that could be formed around a group of methods and responsibilities is a good thing. On the other hand, I’m uncomfortable with the idea of leaving code behind that’s confusing to people less experienced than me.

What do you think?

DRY up your Cucumber Steps

Update (13th Jume 2012): This is an old, old post that still gets a lot of hits. I don’t recommend this practice anymore. Instead, I recommend composing Ruby methods that carry out these actions. For more details, please see The Cucumber Book.

A while back, I asked the Cucumber team for the ability to call in the steps of one scenario from another.

The canonical example of this is the ‘log in’ scenario:

Scenario: User logs in
  Given there is a User whose username is "matt"
  And I follow "log in"
  And I enter "matt" in "username"
  And I enter the User's password in "password"
  And I press "Log In"
  Then I should be logged in
  And I should see the text "Hello matt"

Phew. Now obviously I don’t want all this noise in the scenario every time I specify behaviour that requires a logged in user. I want to write something like this:

Scenario: User views their dashboard
  Given I am logged in
  And I follow the "dashboard" link
  Then I should see "This is your dashboard"

Thanks to the fabulous creativity of the Cucumber community, this is now possible. It’s also highly recommended, as it’s a great way to help you keep your step files tidy and DRY of excess duplication.

Given /I am logged in/ do
  steps %{
    Given there is a User
    When I follow "log in"
    And I enter "#{User.first.username}" in "username"
    And I enter "#{User.first.password}" in "password"
    And I press "Log In"
  }
end

I’m doing this more and more now – writing simple ‘building block’ steps and assembling them to make steps that read nicely and make sense to the stakeholders.

“Total Programming” and the XP Team

Pair programming brings a great many benefits to a team that’s truly mastered it.

Those of us who are lucky enough to have experienced working on a really effective XP team know about that almost magical thing that starts to happen when the barriers between different members of the team break down, egos and code ownership are cast aside, and the team starts to evolve the codebase as one, mighty, coding machine. It’s truly a joy to be a part of, or even just to watch.

dutch-team-78

Continue reading ““Total Programming” and the XP Team”

Your Private Methods are None of my Business

A common sloppy mistake I see programmers making is to forget to declare a method as private when it’s only being used inside a class. This seems to happen more in Ruby, or maybe it just bothers me more because we don’t have interfaces. Rails ActiveRecord validation callbacks are a classic example where people often forget to do this.

Continue reading “Your Private Methods are None of my Business”

I am Extreme

I going to be speaking (with my good friend Rob Bowley) at the forthcoming XP Day conference in London, 11th & 12th December 2008. Which means that I am now officially extreme. Dude.

Come to my talk if you want to hear my experiences of breaking a team out of the Scrum mould and doing some exciting stuff with value stream maps, Kanban boards and other techniques from the school of Lean Thinking. Come along if you want to hear about a world without task cards, exhausting planning days, and maybe even a world without estimates. Sorry Jason, but there may be some mention of coloured bits of card.

I’m actually one of only a few people with a scheduled talk, as the organisers have decided to use an open-space format this year. Which means you also have a chance to get up on stage and lead some discussion. After my last experience with an open space, I’d say it’s well worth doing your homework and really thinking about what you’d like to discuss at the conference beforehand so that you get the most out of it.

If you’re interested in building software as well as you can, XP Day is a great place to meet like-minded people, share experiences and develop ideas. It’s only small, so register soon!

Let me know in the comments if you’re coming, and what you’d like to talk about when you get there.

Ubuntu Eee – The OS Your EEE Should Have Been Born With

On finishing a long contract and project at the BBC a few months ago, I was incredibly touched to be given a brand new Asus EEE PC as a leaving gift by my colleagues.

Although I loved the tiny form factor and take it with me practically everywhere, I was never quite satisfied with the default Xandros Linux and have fidgeted around ever since trying out different options, spending way too much time on the on the excellent eeeuser.com community site, zapping the flash drive with different distros.

Finally this evening I think I found the answer: http://www.ubuntu-eee.com/

Slick, easy to install, great looking, and of course a proper operating system under the hood. Props to the team who put this together, it’s terrific. If you have one of these little beauties yourself, I highly recommend checking it out.

Logging HTTP Error Messages in Ruby and Rails

Rails comes with some default logging stuff built in, but if you’re used to the sophistication of the log4x frameworks, it’s pretty basic.

One of my requirements is to be able to log exceptions that occur during an ActionController HTTP request, and have the configurable logging mechanism decide what to do with them – most likely send emails and write to syslog in production, in development I’ll want it to write to a file and maybe growl.

Looking around the web, there was a project to port log4j to Ruby, but it appears to be moribund. The imaginatively named Logging framework looks a lot more lively and mature. I mean, it’s on github… What more could a budding Ruby hipster possibly want?

Continue reading “Logging HTTP Error Messages in Ruby and Rails”

Is the Value Fetish Killing Agile Teams?

Last weekend I was at CITCON Europe, a great opportunity to meet some of the leading minds in the agile software movement. One intriguing new term I heard a few times was “value fetish”. Let me try to explain what I think it means, and discuss the implications for agile teams.

Continue reading “Is the Value Fetish Killing Agile Teams?”