Once upon a time, around 30 years ago, there was something called Extreme Programming. XP was an agile methodology (only the word agile wasn’t used and abused then). It sounded cool, and there was a reason for that choice of word. The meaning behind “extreme” was meant as “everything we do, we take to the extreme” as Kent Beck said.
Mind you, it’s also a problematic name, because it sounds risky. No one in their right mind, in the risk averse software world, would try (or approve of) anything “extreme”, right?
But we’re not here to grade names. We’re here to talk about one of the principles of XP: Pair programming. Sometimes you may hear people call it as “extreme programming”, but this is incorrect. Also, it’s not really extreme. Although, I can see why people would name it like that.
Why would you pay two developers to work on something that one developer can do? It doesn’t sound economically viable.
Ah, but there’s a small, hidden assumption in this kind of economic thinking. We assume that what one developer can do, one does it right. And one really doesn’t. Otherwise we wouldn’t have bugs, and code reviews, and all kinds of meetings.
Funny thing – in a world where developers work on their own, we still have those meetings, and the bugs keep coming. Even when developers work in isolation on their own tasks without interruptions.
When Two Become One
The idea behind pair programming is very simple. We can’t trust one developer to do their tasks right, as proven by reality. But two people – we can trust.
After all, that’s the reasoning behind code reviews. We do those all the time because we need another witness to the crime. Or, hopefully, disrupt it before it happens.
Code reviews are usually not that effective (because we do them wrong, check out this post) .
But if they are done right – two people, sitting together in front of the same screen, at the same time, discussing pros, cons and code – code reviews become really effective. Fewer bugs escape, knowledge grows in the team, and there’s a mutual agreement that the code coming out, is in its best possible form.
While code reviews are effective, they are not efficient. We can review code, only after it’s been coded. This means we’ll need to catch all the wrong stuff (which doesn’t happen a lot. The catching, not the wrong stuff), then fix all of it (which doesn’t happen a lot either).
Then, there are the delays between “done” (before the review) and “really done” (after the review). And remember, this happens with the effective reviews.
Turns out, that having two people work on the same computer at the same time, reduces those delays, because problems are found early, sometimes before the code is even written.
Two minds are working on the same problem, and they get to an agreed solution, and only then code it. Of course, this process also means less escaping bugs. The whole timeline to “really done” shrinks.
The Social Net Work
There’s even a hidden benefit to pair programming that speeds things up. While working in pairs, I will not be scrolling through TikTok. We don’t find it socially acceptable. So we are working on the problem together, completing it faster.
Also, if I see someone working alone, and I must discuss the latest news on my new Pokemon game (as it happens to everyone), I will do it – right now. But if you I two people working together? I’ll postpone the gratification of sharing the news. Again, it’s not socially acceptable, and the result again is the problem gets solved early.
The timeline to “done” really shrinks.
If two developers were working alone on their own tasks, we would get two “almost done” features. Instead, we get at least one “really done” task, sometimes two. Those are features we won’t need to revisit. We’ve done the code review on the job. No extra meetings needed.
They are Done-Done. Done.
Pair programming is not foolproof, and it may not be a great fit for all the people in the world, all the time. But it does work. I worked more than 4 years, most of my development time, like that.
Past Pair
Pairing doesn’t have to be “programming”. Eons ago, when I was a team lead, I had a developer on my team working on the UI, and a tester who had experience in chemistry, but not much in software. And there was a raging battle between them.
The developer didn’t understand what he was doing wrong. The tester didn’t know anything about code, but was really furious every time she got a buggy build. And that happened a lot.
So I sat them together for a couple of hours everyday. This is before I knew how to even spell Agile. They paired on the developer’s computer, built what they discussed, saw it working, and the bugs stopped visiting.
I wasn’t aware at the time I was doing something extreme, but the improvement in quality was extremely noticeable.
If you’re thinking “that’s not for me”, try to remember the last time you had a bug. You were investigating it for half a day already, and then said to your colleague: “can you come over and look at this problem?”. At that point you were already pairing. And it’s not for programming, as you can probably see.
So why not do more of what works? Try it like two hours a day. Or twice a week. Even once a week with the whole team (That’s called “mob programming”, and it achieves the same results). Try it in small doses, and increase when you see success.
Pairing may not be easy, but it’s very effective in delivering working software.
And what’s our goal again? Deliver working software
Amazing, I know.
Speaking of pairing, my workshops exercises are done in pairs. So even if you lived in a cave, letting no one in there, you can still try to feel the experience, for example in my Unit Testing Workshop.
0 Comments