Why pair programing is as much about business continuity as it is about code quality.

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, 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 how it did it, confusion turned to horror, did anyone know what this guy’s code was like? What if he left for good, got hit by a bus? Was this module going to rot forever or need rewriting?

I realised I’d heard this in a different form some time previously in another organisation 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, result in less bugs etc. This is understandable as these are the benefits most obvious to developer. But I would argue that it is business continuity that could 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.

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) 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 of it.

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 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 be one big blob of software. I have seen pairing address this in this way: as pair’s rotate, realising 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 individuals baby. I have seen pair programming to be an extremely powerful way to ensure this is the case. If your organisation is developing software the question you should be asking is not can you afford to have developers pairing but can you afford not to?

dave speaking

 

Watch my talk at the pipeline conference where I discuss introducing pairing and other XP practices to a team.

 

 

 

Advertisements
Tagged , ,

7 thoughts on “Why pair programing is as much about business continuity as it is about code quality.

  1. I think knowledge sharing and pair programming are two separate things. Knowledge sharing is a product of pair programming, but pair programming is not the only way to share knowledge.

    Personally, I can’t write code with some other person all the time. I enjoy sitting and coding with someone for a day, or a couple of days, but then I need to crack on.

    I find its like trying to paint an oil painting with someone else. For some stuff its fine for two people to sit and discuss and code a bit here and there, but for laying down a large amount of code, or complex, recursive logic, it doesn’t work.

    Its impossible to communicate the enormous amount of brain processing going on via words, or words and sketches. Progress slows to a crawl and then I don’t maintain the mental speed needed not to lose my own train of thought.

    I couldn’t take a job where pair programming was the main way of working. Knowledge sharing, showcasing code, communicating new classes and designs and APIs is preferable to me.

    Moreover, code should be written in a way that anyone on the team could have written it, with great comments, standard patterns and practices and sticking to API + language guidelines.

    I’ve also recorded videos for more stuff like lesser-used manual processes.

    Like

    • thinkfoo says:

      Luke, thanks for taking the time to read and comment on my post. Whilst I agree with you that pairing is not the only way to share knowledge in a development team you won’t be surprised to hear that it is, in my opinion, probably the most effective way to do so.

      Its my experience that by collaborating on the problem solving at the time the code is being developed through discussion, tests, sketches, trial and error etc. we gain a shared understanding of not just how code ended up but also, crucially, how we got there and that this is a far deeper understanding than any code review could ever achieve.

      I also agree that code should be written in a way that anyone on the team could have written it and I know of no more effective way of getting this than having worked on it together in the first place.

      But beyond this I think the shared ownership that comes from pairing and pair rotation could never be gained from any kind of showcase is key to developing a product that is an asset to a company rather than as I said one individuals “baby”.

      Like

  2. Davide Finardi says:

    I can’t agree more. We recently faced a similar issue in our team when the most senior designer decided to leave the company. I took over all his code while others were so scared to fail and got more or less stuck where they were. I tried a number of ways to mobilize them with poor results, then I tried pair programming, at least a “kind of”. It worked and allowed another team member to grow in competence and confidence on our block. While others went for more traditional approaches and lost weeks with poor results, we did it in the days. I will try to repeat the experience again in our new assignment provided management does not interfere. Let’s keep finger crossed!

    Liked by 1 person

  3. […] my post on pairing for my views on why this is essential to building quality software […]

    Like

  4. You don’t have to do pair programming to ensure business continuity. All you need is to ensure that all developers work with different parts of the code.

    The other tools that while giving us more benefit then pair programming while costing less is peer code reviews.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: