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

Lessons learned from some of the best Ruby codebases out there (part 3)

(Important note: This was originally published on the Blacklane dev blog - I’m just putting this up here as kind of mirror) Welcome to the third part of the series - you can find the first part here and the second part here. In this part... Continue →

Subscribe to Timo Rößner

Don’t worry; we hate spam with a passion.
You can unsubscribe with one click.