Did I mention that I like pair programming? Here are some reasons why it’s good for you and your boss.

More Trucks

The higher the truck number of your team, the more resilient it is to losing people. Pair programming spreads knowledge of the code around the whole team meaning each team member has a much more broad knowledge of the system than on a traditional team.

Free Training

Every time I pair with someone, I learn at least one new trick, be it a keyboard shortcut for my editor, a new command-prompt command, or a language idiom. This training costs nothing and builds the confidence of even the most junior team members who always have something to contribute, to say nothing of how much they will learn from sessions with their more senior colleagues.

Team Bonding

Working together in pairs breaks down barriers between people much more quickly than when they are working alone, and provides a natural environment for teams to learn to trust one another, and enjoy one another’s company. These are vital attributes that will get your team though the tough times, ensuring they can pull together when necessary.

Better Designs

Experienced programmers know that coding is much more a process of design than of mere implementation. When subjective design decisions are taken by at least two people on the team, those decisions have much more authority and are more likely to be understood and accepted by the rest of the team than if they had been taken alone. When one member of the pair has a good idea for a solution to a problem, this may stimulate an even better one from their pair. Science says so.

Less Bugs

The perpetual code review that’s done during a pairing session not only produces better designs, but it also catches a lot more defects as they are written. Pairs will tend to write more thorough automated tests, and are more likely to spot holes in logic that would otherwise have to be picked up by subsequent manual testing.

More Fun

Generally, programming in pairs makes for more a more relaxed and enjoyable atmosphere in a team. People become comfortable with their own strengths and weaknesses and are able to talk and joke about their work much more readily, since they are already used to that dialogue. This is obviously terrific for morale and staff retention.

More Focus

Pair programmers do not check their emails when they’re waiting for a script to run, disappear into their inbox for 20 minutes, then come back and have to remind themselves what on earth they were doing. When they hit a little break-point, they review what they’ve done so far and make a plan for their next steps. They stay focussed. Twitter can wait.

I’ll be running a preview of my Agile 2009 workshop ‘Debugging Pair Programming’ at Skills Matter on Monday 10th August.

If you’re on a team that’s using or trying to adopt pair programming, this is a great chance to explore and understand some of the complex reasons why this is such a difficult skill to master.

The session is free, so sign up soon to avoid disappointment: http://skillsmatter.com/event/agile-scrum/debugging-pair-programming

Estimate: an approximate calculation of quantity or degree or worth

Commitment: the act of binding yourself (intellectually or emotionally) to a course of action

• Estimates are not commitments.
• Plans based only on estimates are bad plans.
• Commitments based only on estimates are at best foolish, at worst dishonest.

Estimates are certainly a useful tool for making realistic commitments, but there are many others too that are equally, if not more, useful. Working at a sustainable pace, measuring data about past performance, and facilitating the genuine consensus of the whole team when committing are the way to make plans that can actually be achieved.

At work, we have been practising something approximating Acceptance Test Driven Development now for several months. This means that pretty much every feature of the system that a user would expect to be there, has an automated test to ensure that it really is.

It has given me a whole new perspective on the value of tests as artefacts produced by a project.

I made a pledge to myself when I started this new job in August that I would not (knowingly) check in a single line of code that wasn’t driven out by a failing test. At the time, I thought this would always mean a failing unit test, but I’m starting to see that this isn’t always necessary, or in fact even wise.

Don’t get me wrong. Unit testing is extremely important, and there’s no doubt that practising TDD helps you to write well-structured, low-defect code in an really satisfying manner. But I do feel like the extent to which TDD, at the level of unit testing alone, allows for subsequent changes to the behaviour of the code, has been oversold.

If you think you’re doing TDD, and you’re only writing unit tests, I think you’re doing it wrong.

As new requirements come in, the tensions influencing the design of the code shift. Refactoring eases these tensions, but by definition means that the design has to change. This almost certainly means that some, often significant, portion of the unit tests around that area of the code will have to change too.

I struggled with this for a long time. I had worked hard on those tests, for one thing, and was intuitively resistant to letting go of them. More than that, I knew that somewhere in there, they were testing behaviour that I wanted to preserve: if I threw them out, how would I know it still worked?

Yet those old unit tests were so coupled to the old design that I wanted to change…

In my mind, I have started to picture the tests we write to drive out a system like little strings, each one pulling at the code in a slightly different direction. The sum total of these tensions is, hopefully, the system we want right now.

While these strings are useful to make sure the code doesn’t fall loose and do something unexpected, they can sometimes mean that the code, like Gulliver in the picture above, is to restrained and inflexible to change.

The promise of writing automated tests up front is regression confidence: if every change to the system is covered by a test, then it’s impossible to accidentally reverse that change without being alerted by a failing test. Yet how often do unit tests really give us regression alerts, compared to the number of times they whinge an whine when we simply refactor the design without altering the behaviour at all? Worse still, how often do they fail to let us know when the mocks or stubs for one unit fail to accurately simulate the actual behaviour of that unit?

Enter acceptance tests.

By working at a higher level, acceptance tests give you a number of advantages over unit tests:

• You get a much larger level of coverage per test
• You get more space within which to refactor
• You will test through layers to ensure they integrate correctly
• They remain valuable even as underlying implementation technology changes

Admittedly, the larger level of coverage per test has a downside: When you get a regression failure, the signpost to the point of failure isn’t as clear. This is where unit tests come in: if you haven’t written any at all yet, you can use something like the saff squeeze to isolate the fault and cover it with a new test.

They’re also much slower to run, which can be important when you’re iterating quickly over changes to a specific part of the system.

To be clear, I’m not advocating that you stop unit testing altogether. I do feel there’s a better balance to strike, though, than forcing yourself to get 100% coverage from unit tests alone. They’re not always the most appropriate tool for the job.

To go back to the metaphor of the pulling strings, I think of acceptance tests as sturdy ropes, anchoring the system to the real world. While sometimes the little strings will need to be cut in order to facilitate a refactoring, the acceptance tests live on.

The main thing is to have the assurance that if you accidentally regress the behaviour of the system, something will let you know. As long as every change you make is driven out by some kind of automated test, be it at the system level or the unit level, I think you’re on the right track.

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!

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
  Given "there is a User"
  Given "I follow \"log in\""
  Given "I enter \"#{User.first.username}\" in \"username\""
  Given "I enter \"#{User.first.password}\" in \"password\""
  Given "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.

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.

Continue Reading »

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.

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 »