Four super powers that you wish you had
Image taken from the 2008 film “Hancock” (Colombia Pictures) starring Will Smith and Charlize Theron
Extreme Programming Pairing
One of the more controversial techniques that XP employs is Paired Programming. Paired programming is when two developers work on a single task, using one computer. Its a simple concept – one person types, while the other watches. The original XP rationale behind paired programming goes along the liens of “code reviews are good, therefore we should do them all the time”.
Pairing is not difficult to do well, but it is also easy to do badly. To do pairing well, both partners need to be actively engaged all the time. A secret-sauce of pairing is that merely the act of explaining what you are doing – talking aloud through your thought processes – helps cognitively. This works even if you are talking to a stuffed Teddy Bear, apparently (I’ve never done that myself!). So a successful pair will be one that is constantly talking to each other. One of the more powerful metaphors for successful pairing is the Rally Driver and Navigator. The Driver is the person concentrating on the immediate code at hand and typing, while the Navigator is looking ahead, anticipating problems, and providing additional insights to the Driver. Pairing can also be done as a teacher/student pair – where the person at the keyboard is a less experienced programmer, or one learning a new code base. It can be done as a developer/tester pair. One of the common patterns when two developers of similar skills are working together using Test Driven Development (TDD) is ‘ping pong’. One person writes the unit test, then the second writes the code. The second person then writes the next unit test, which the first then writes the code for.
A much-lauded benefit of pairing is that quality is increased. After all, that is why it was thought of in hte first place – it provides a forum for continual code reviews. The argument is that the apparent loss in productivity by putting two people on the same task, is in fact made up by the incrased quality. Given that it recent estimates have ‘rework’ (bug fixes at all stages of the development cycle) as a result of lapses in quality results in anywhere between 50-70% of the average overall time spent on development. All of a sudden, putting two people on the job to eliminate (or at least substantially reduce it) no longer feels like wasted overhead!
Four Super Powers of Pairing Teams
In addition to the well-known quality argument in favor of pairing, there are a few lesser-appreciated ‘super-powers’ that a team that is good at pairing, and that pairs often, has. In my mind these super powers are at least as significant as the increase in quality.
Super Power #1: Anti-Interruption Shielding
As highly cognitive knowledge-work, programming often induces a state of ‘Flow’ in developers. ‘Flow’ is those periods of high focus and productivity that make you lose track of time. It is often induced when performing cognitive tasks that are challenging but accomplishable – which describes most development. However, it is well known that interruptions can disrupt this flow. It can easily take 15 minutes to get ‘back into the swing’ after an interruption. Pairing, however, provides a powerful shield against interruptions. Even though one of the pair might be interrupted to respond to a question, answer a phone-call, go the bathroom, or just take a break, the other can stay working focused. As soon as the other partner rejoins, the pair quickly falls back into Flow. This even works when both take a break – they help each other get back into Flow. This superpower means that a pair can stay focused and highly productive for much longer than a single developer. Given the amount of time that the average worker spends looking out the window or thinking of other things besides the task at hand, this is an amazing superpower to have.
Super Power #2:Attrition Resilience
What happens when you database guy is sick or on holiday? Or if you have several contractors on your team, and one day they all decide to leave to go to work for a start-up? If you are like most organizations, you lose those days of productivity. If you team has been pairing, then well…nothing happens. Because every team member is familiar with every piece of code, and every developer is T-Shaped, the team is highly resilient to disruptions in day-to-day changes in composition, and can even survive a mass exodus without being wiped out. In the case of a mass exodus, not only can the ‘last man standing’ continue to develop working, valuable code, but, through utilizing the next super power ‘Power Leveling’ can quickly get the team back on its feet.
Super Power #3: Power Leveling
When I was seven years old I didn’t fancy the prospect of another 14 years at school – at that time I wasn’t much of a fan of the institution. I used to dream of a pill that I could take that would instantly give me all knowledge. Then came along the Matrix – the modern version of my pill – an instant upload. How cool would that be? Pairing doesn’t give you a magic pill, nor does it enable you to jack in to the entire body of human knowledge. It does, however, provide a team with an extremely powerful learning tool. In the teacher/student mode, less experienced programmers can be taught new skills, new employees can be ramped more quickly, and the team can disseminate best practices faster and more effectively than any other method that I know of. Individuals are learning in one of the most powerful ways possible – in context and interactively. The mythical beast the ‘T-shaped Developer’ can be spawn this way too – these are developers who have one or more specialities (the down-stroke on the ‘T’), but who have general confidence across the entire stack (the cross-bar of the ‘T’).
Super Power #4: Myth Busting
Fred Brook’s mythical man-month fallacy (encapsulated in Brook’s Law: “Adding manpower to a late software project makes it later“), is caused by the fact that “Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers …the time required for the new programmers to learn about the project and the increased communication overhead will consume an ever increasing quantity of the calendar time available.” Pairing changes that dynamic. It is no longer necessary to split projects into discrete tasks, because multiple workers can work on the same task. Indeed one of the techniques that I have developers practice when they are training with me is Swarming. This is where the entire team works on single story or task. During a Swarm performed as part of a pairing exercise, pairs are regularly rotated, thus solving the communication overhead without incurring the ‘increasing quantity of calendar time”.
