Jumping off the pair programming bandwagon

For quite some time, a lot of companies have been on the “yes, we do pair programming” bandwagon and still are. Some of them even to the (ridiculous) extent that pair programming was or is mandatory a la “at least 2 days a week”.

I’ve been through that and those were certainly some bad times in my software development career.

I have always been sceptical of pair programming to begin with.

First of all, it’s synchronous. You have to pay attention that very same time your partner pays attention. But people and their rythm are different and if you do this all day, this gets exhausting very quick.

Second, regardless of what technology you’re using, there will always be artefacts you have to generate and update, tests to run, a network connection you wait for and so on. If you use a language or framework that is more machine-friendly than developer-friendly this might amount to a lot. But even with something developer-friendly like Ruby, Python or Elixir this will steal a lot of your time.

And during that time one partner takes care of those mundane tasks the other drifts off - there’s just nothing you can do about it, this is how most humans work. And if one partner looses focus, he takes the other one down with him ususally.

So in a nutshell, there are quite a lot of situations where pair programming sucks hard.

 So what are the alternatives?

Pull requests.

They share a lot of benefits with pair programming but don’t have a lot of the disadvantages.

Most importantly: They are asynchronous by design so you can dive into problems when you feel like. Your time, your speed. Very important.

Besides that it is still collaborative. You can still have a conversation in that pull request that is (almost) as precise as if you would be sitting right next to somebody.

The biggest advantage is the biggest downside as well: Due to the asynchronous nature there might be some delay in communications. This is something though that is fixable with a good development culture.

Of course there are a couple of exceptions though where pair programming makes not only a lot of sense, but offers significant benefits:

 Wrapping it up

I guess with pair programming it’s like with everything in life: We shouldn’t make up rules just for the sake of having them and follow them without questioning them.

I believe we should use pair programming judiciously - quite often we can achieve the same thing better with pull requests.


Now read this

Kill all the mutants - a deep dive into mutation testing and how the Mutant gem works

As part of a presentation I’m hoping to give at the end of this year about abstract syntax trees and how you can leverage them I started to look into how the Mutant gem works. Mutant is the by far most advanced gem for doing mutation... Continue →