Tea-Driven Development

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.

I’m just back from this year’s XP Day, London. Thanks to everyone who came and packed out the room to hear Rob and I talking about our experiences evolving our team from Scrum to Kanban. The slides are here.

There’s also a great transcript of the talk here on Tom Hume’s blog. Thanks Tom!

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.methodname. > > I see def self.methodname 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
 attrreader :temperament
 def initialize(temperament)
 @temperament = temperament
 end
 end

class Dog
   attrreader :temperament
   def self.newhappy
     new(:happy)
   end
   def self.newangry
     new(:angry)
   end
   private
   def initialize(temperament)
     @temperament = temperament
   end
 end

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

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
   attrreader :temperament,  wner
   class << self
     def newhappy(owner)
       new(:happy, owner)
     end
     def newangry(owner)
       new(:angry, owner)
     end
   end
   private
   def initialize(temperament, owner)
     @temperament, @owner = temperament, owner
   end
 end

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

And what does our Dog class look like now?

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

class Dog

  def self.newhappy(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?