Pair Programming Supports Business Continuity
Pair programming is sometimes considered to be too expensive by leadership, but if someone leaves, pairing makes up for brain drain since everyone knows how everything works.
Join the DZone community and get the full member experience.Join For Free
I heard a statement recently, it’s a common problem and is probably familiar to many of you.
It goes something like this: “We will need to wait until next week when Max is back from holiday to do that work, that module is his baby ”
When I heard this my initial reaction was confusion. Why was no one else able to work on this code? It was in the same language, the same repository, was built in CI, and had tests; it made no sense. Then it dawned on me no one else in the team had EVER worked on this module, they had no clue what it did it or how it did it. Confusion turned to horror; did anyone know what this guy’s code was like? What if he left for good, or got hit by a bus? Was this module going to rot forever or need rewriting?
I realized I’d heard this in a different form some time previously in another organization from a new CTO who had not had extensive experience in a pairing environment: “So Paul is leaving, what do we need to do for handover? ”
It left us old hands a bit stumped. Sure we were losing a very talented developer but there was nothing unique about his knowledge of our code that needed “handing over”.
The common negative response to pair programming from management is “I can’t afford to use two people to do one persons job” . As developers our common reaction to this is to explain how pairing can be faster and result in less bug. This is understandable as these are the benefits most obvious to developer, but I would argue that it is business continuity that can be the killer argument for pairing.
Done correctly, pairing addresses business continuity in a number of ways:
Knowledge sharing – Many people have actually worked on the code. This is far superior to a code review. Think of pairing as having co-written the book, and code review as being told the story by someone who has seen the film adaptation.
Code becomes easier to understand on each pair rotation (pairs should rotate or swap partners at least once a day to reap the benefits of pairing), and as this rotation occurs small improvements in code clarity are made as the new person gets their head around what’s been done so far. This makes it a much more valuable and flexible piece of software six months down the line when some new requirement is needed.
No ego’s — The code is collectively written and ergo is collectively owned. No need to wait for Max to get back from holidays; if it needs changing today it can be worked on today without upsetting anyone.
It’s a truism to say that code takes on the form of the team or teams that write it. If only one developer is working on a system, the benefits of breaking down the code into modules are diminished since a single person can only work on a single piece of code at a time. This is one reason why it’s common to see software written by a team of single developers become one big blob of software. I have seen pairing address this in this way: as pairs rotate, realizing that a piece of work can be done in parallel if the code is structured in a particular way, they do so and your most important feature gets into your customers' hands faster.
The software a company builds should be considered a company asset, not some individual's baby. I have seen pair programming be an extremely powerful way to ensure this is the case. If your organization is developing software, the question you should be asking is not whether you can you afford to have developers pairing, but can you afford not to.
Published at DZone with permission of David Hounslow. See the original article here.
Opinions expressed by DZone contributors are their own.