Yesterday I talked about some relative pros and cons of pair programming and pull requests.

Today I want to talk about two other concepts, that I believe often influence the balance of these pros and cons: Utilization and Flow.

Most of us, it seems, have been trained in professional life, to value utilization. Put another way, when we’re not busy “doing work”, or when we’re underutilized, we feel like we’re wasting time. Possibly even “stealing” from our employer.

This often leads to a number of unhealthy habits, many of which stem from the problem of starting too many things at once. “I’ve done all I can on project A for the day, I’ll start on project B.” This leads to additional context switching, which, when taken too far, can result in lower quality outputs, and many other problems.

There’s another concept which traditionally has been often overlooked, but is gaining a lot of attention in the software world these days: Flow.

To simplify, flow is the way work moves through a system. When we examine flow, we look for places where work stops, while waiting for something to happen, or maybe even backtracks, to fix a defect, for example.

Utilization and Flow are two different ways to look at a system. And depending on which one we prioritize, we’re often inclined to make very different, sometimes even opposite, decisions.

To illustrate, imagine you work in a strawberry packing plant, which is focused on strawberry packer utilization. So you’re sitting there, hour after hour, packing strawberries.

Meanwhile, it turns out the truck to ship the strawberries to their retail locations has a flat tire. So the strawberries are just piling up.

Not very effective.

If we were to shift our focus to the flow of strawberries, rather than the utilization of the packers, we would probably tell all of the packers to stop packing strawberries for a while. Take a long break. Or maybe do some other work–like fixing the flat tire?

So how does any of this relate to pair programming versus pull requests?

Pull requests are one tool that is often used as a way to increase utilization. “When you’re done with that feature, start on the next one until the PR is reviewed.”

It’s well intentioned, I’m sure. We surely don’t want to waste the time of our highly paid developers!

But what is often lost sight of in this, is that flow is actually what matters the most. Having 18 pull requests waiting for code review doesn’t serve customers.

Shipping features to customers does serve customers.

If we shift our focus from utilization (make sure those devs are always busy!) to flow (make sure we’re getting features to users quickly!), we’re likely to put a lot more weight on the slow cycle times of PRs vs the fast cycle times of pair programming. And we’ll be a lot less concerned about “making sure the devs are always busy.”

Now let me re-iterate: PRs and pair programming are not the only options. I hope I made that clear yesterday. I’m using these two options as anchors for discussion.