Programmer productivity: SP < PR < PP < MP

In my experience, when it comes to programming productivity, mob programming beats the rest. Of course the definition of productivity in this context is debatable and these are just my observations. Thus, it is not a proper scientific study but bear with me anyway.

I wish to compare one aspect of productivity, how we work together. I look at single programming, pull requests, pair programming and mob programming.

Productivity

What is productivity then? If you consider code as a liability instead of an asset, the more code you produce, the worse. What you should produce is features. That would be programmer productivity but not necessarily the best thing to do, it is the production of the right features that matters.

Given that we are handed the right features, how can we measure productivity? I typically use throughput, how many stories we finish per sprint.

An interesting thing about productivity is that it is taken very personally. It shouldn’t, unless you’re refusing to change when learning new things. The heaviest impact on productivity comes from the environment, such as the effort to deploy to production (which is what “done” means) or colleagues that are unwilling to change work habits, to mention a few examples.

But let us compare single programming, to pull requests, to pair programming, to mob programming.

Testing

First of all, in all of the cases below, we assume that unit tests are written. Working software is what counts and with no testing, it is a lot more likely to be broken.

Single Programming

Sitting by yourself in a quiet room hacking away, wonderful, isn’t it? I enjoy that a lot and time just flies. But not at work, that is at home with my hobby projects. They never get finished. At work, who has a quiet room? Headphones help but you still get disturbed by people who need your input, your help, your time report, your participation in a prestudy, your presentation, your job interview, your IT support, your comment on the music scene or a cinema premier.

Do you ever think, “if I just could get the time to really focus”? When you get stuck, it might not be easy to ask for help since everyone else is busy with theirs. You are vulnerable when you are alone.

Single programming is the lowest level of productivity, the ideal circumstances it requires simply isn’t there.

Pull Requests

With the open source community getting more organized with the help of GitHub, the use of pull requests has spread. Open source projects have a maintainer who evaluates pull requests from other developers who want to support the project. The maintainer can ignore pull requests or pull in the changes as she pleases. Open source is seldom paid work and lacks deadlines.

Now this has spread to the rest of the programming world where people are paid by the hour, software is developed against deadlines and programmers sit in the same room. Quite different from the open source scene.

It is the good old code review that has made a come back and it has it’s advantages. If you for some reason need to sit by yourself and code, a pull request guarantees that someone else is reading your code before it gets into production.

However, you need to wait for that person to be available and that bogs down your throughput. If your team visualises the wait for a pull request to be accepted, I guess that if you look now, there are a few waiting. Once the review happens, any rework needed will likely interrupt the current work and cause task switching.

Pull request is the second lowest level of productivity.

Pair Programming

Pair programming was popularized by the Extreme programming movement. With pair programming, the code is immediately and continuously reviewed by a peer. A very short feedback loop. The result is learning as well as fewer defects. Also, pairs tend to consider more design options.

If you get disturbed, it is easier to find focus again as you can help each other. Generally, the focus stays better with a pair than a single person.

Pair programming is a skill that has to be mastered. Important factors include how often you pass the keyboard, how you communicate, how you handle interrupts and how you pick your partner.

In my experience, pair programming is the second highest level of productivity, only beaten by mob programming.

Mob programming

Mob programming was made popular by Woody Zuill but is also related to Extreme Programming.

Is it really a good idea to have the whole team focusing on just one thing? Wouldn’t we get more done if we work in parallel?

I’ve tried mob programming with two teams at completely different companies. The result was the same, both teams produced more with mob programming than with any of the other techniques mentioned.

Mob programming is harder. You need to have even more working agreements than with pair programming and you need to see that productivity increases or you will give up. Why? Mob programming can be exhausting as more people working on the same thing means more ideas and suggestions that you need to take in.

In pair programming, you solve the low level issues while your partner thinks ahead strategically. Now you’re supposed to be more like a robot when you have the keyboard.

But if you stumble on an impediment, you can just send a mob member to deal with it while the rest of you keep going. A well functioning mob is like a bulldozer, it just rolls on.

Mob programming is the highest level of productivity, but it has a steep learning curve and you need to invest in the way you arrange your workplace.

Summary

Mob programming beats pair programming beats pull requests beats single programming, MP > PP > PR > SP, when it comes to producing features quickly. But it takes dedication, learning and energy to climb that ladder.

You might not agree with me and your mileage may vary. But I find it funny that people are very sure which one of these techniques is best suited when they have never tried them seriously. Don’t be one of them.