Wynton Marsalis, one of today’s greatest trumpet players, can certainly speak about “doubling up”: he has won Grammys for both classical and jazz music, and he does not only compose music and play the trumpet, but he’s also an educator and an artistic director at the Lincoln Center in NYC. So, when he tells you that “there’s no right or wrong, just some choices that are better” you should think about trying options by yourself and see if they work out!

Scrum is a project management framework, which usually imports several practices from Extreme Programming (XP), such as TDD, Refactoring, User Stories, and more. So, in the spirit of experimentation and making choices, why not consider adding other XP practice, and have your team do pair programming?

The idea behind Pair Programming is that all code is written by two people, working together at a single computer, with a single keyboard, and a single mouse. At any moment, one of the pair will be “driving” –i.e., writing actual code– while the other will be paying attention, suggesting changes, giving help, and eventually taking over driving, so both roles will be reversed often. As time passes, pairs are changed, so everybody gets the chance to pair program with everybody else.

This practice may seem counter-intuitive —two people doing the job of one!— but it has been repeatedly shown that there are important savings afterwards, in bug fixing time, because the produced code is of higher quality: you won’t save money at the start of the project, but all throughout its later life!

There are some other possible problems. Pair programming, as a skill, takes some time to learn, and not all developers are equally adept at this way of cooperation. It’s quite likely that there will be problems at the start, because not everybody will adjust. However, given time –and, even better, with coaching from somebody with previous experience in the practice– most programmers will adjust. In a sense, this is similar to TDD: not everybody likes writing tests or even accepts the idea, but the proven results are usually enough to convince them.

On the other hand, there are other advantages and benefits:

  • Code quality: as the code design is done by two people, it’s less likely that there will be defects as you could find in a later peer review phase.
  • Interruption handling: if there are interruptions (as there always are!) it’s possible that the partner who is not driving, will be able to deal with it, without breaking the flow of the driver. And, having to interrupt TWO people may discourage some would-be interrupters!
  • Knowledge Transfer: everybody in your team will have some knowledge that the others don’t share; pair programming allows for such knowledge to be gained by everybody.
  • Team forming: people get to know each other faster when they do pair programming, and this can help forming an actual team.
  • Collective Code Ownership: when everybody is doing pair programming, and teams are rotated as we described above, all the team members gain at least a working knowledge of your entire codebase, because they will have been exposed to different parts of it with each pairing.

So, as Marsalis suggests, try “doubling up”, and see if this practice helps you produce better code!

P.S: If you want to hear Marsalis playing jazz, watch his take on “Cherokee” — but also listen to him playing classical music, Haydn’s Trumpet Concerto, with an orchestra directed by John Williams, of Star Wars (and many other movies) fame!

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>