Ensemble programming is more efficient

Using Theory of Constraints to understand ensemble programming

Ensemble programming (also known as mob programming) is a way to program where multiple people (more than two) are programming together on one task. Ensemble programming might seem less efficient than pairing (ensemble of size two) or working solo in parallel. But in practice, ensemble programming increases team throughput, which is the correct way to measure a team’s productivity.

Efficiency is the main reason to ensemble program. There are other benefits, but I will focus only on efficiency in this essay. Ensemble programming will deliver more features faster across the entire team. I’ve never met a manager who hasn’t wanted more speed. But the reason it’s more efficient is somewhat counterintuitive. It’s not just more efficient in the long term. It’s efficient for the very next feature you work on.

Many phenomena conspire to increase efficiency. However, the Theory of Constraints, particularly bottleneck analysis, explains why an ensemble can work faster than the same team working in parallel. When you work as a team, you expand the software development bottleneck, significantly increasing your team’s throughput.

The bottleneck of software development for an individual is how long the programmer has a correct understanding of the code so they can proceed productively. As a codebase grows larger and older, the percentage of the codebase that any person understands decreases, so the bottleneck gets smaller. It’s a significant reason that teams slow down as the software grows.

Once they’re stuck, they’re not in a productive process but in a process of getting unstuck. They need to read more code, find documentation, and interrupt other programmers to ask questions. The bottleneck while stuck is the bandwidth of information that directly addresses the problem. The bandwidth is tiny if they’re reading the wrong code or old docs, looking for docs, or waiting on an answer to their question posed in Slack.

When a team ensembles together, the bottleneck is opened up. It’s no longer measured by the limits of one programmer’s understanding. The bottleneck for an ensemble is the maximum understanding among all team members present—not the total understanding but the greatest understanding. If one person on the team understands a corner of the codebase, the team can work at that programmer’s speed on that corner of the codebase. As you add programmers, the maximum can only grow.

The only limit to that growth is the practical limit to how many people can effectively communicate on a single task. It’s definitely above two. It’s less than 10 (the typical guideline for “two-pizza teams”).

The team can still get stuck, but the bottleneck of getting unstuck is opened way up. The communication bandwidth is at a maximum. If no one can directly answer the problem, it’s more likely that someone on the ensemble knows where to look in the docs or what code to read. The ensemble can work productively a higher percentage of the time and can get unstuck faster.

Isn’t working in parallel more efficient?

Yes, working in parallel is more efficient—if your team can. But, like in parallel programming, once one worker has to communicate with another worker, the overhead of communication outstrips the gains in efficiency. On a small codebase, it is easy for every member of your team to have a good understanding of everything. But as your codebase grows, they can’t. And new team members have nearly no knowledge of your codebase. They are stuck a lot.

Won’t some team members be idle?

Yes, and that’s okay. Are you more concerned with everyone being busy? Or delivering more software faster? This is one of the major shifts manufacturing underwent when adopting a Theory of Constraints mindset. Factories went from utilization accounting (maximizing the use of equipment) to throughput accounting (maximizing the throughput of the entire production line). Software teams need to maximize throughput as well.

Can’t I expect individuals to work efficiently?

No, sorry. Developing a software product is a team sport.

If we work on one thing at a time, I can’t show progress on all of our priorities.

If you’re being managed on what work you’ve got in progress, you’re already losing the game. However, there is a chance that if you speed up and exceed expectations, management will stop micromanaging and let you work the way you want. Ensemble programming is the easiest and fastest way to speed up. Toughen up, ignore the heat from management, work smarter, and build trust.

Wait! There are other ways to speed up?

Let’s do the analysis. If programmers need to understand the code to work productively, you can make your code easier to understand. That also helps them get unstuck faster. More and better documentation helps. But how are those efforts going for you?

Another thing you can do is to have a floating senior engineer. You pay them to be idle—literally doing anything besides work—so they can be instantly available to pair with the others if they get stuck. That can work up to a point.

The floating senior doesn’t scale as well as ensemble programming. It’s easy to see why: Any programmer, no matter how senior, cannot know the entirety of a codebase forever. As the junior members build out features, they will be the ones who understand the code better in those areas. That’s why ensembling scales better.

Wait! Do you suggest paying a high-value programmer to be idle?

This is the shift in thinking from utilization to throughput accounting I discussed before. Don’t measure individual utilization. You need to think in terms of team throughput. We’ve already done the analysis. If they’re working on anything productive, they’re back to working in parallel and getting interrupted.

Doesn’t struggle lead to learning?

Perseverance through struggle is something many programmers pride themselves on. We often learned on our own with few mentors to help us. Or we learned in an antagonistic style, such as a boot camp where we were thrown into the deep end. But struggle is not the most efficient way to learn. Immersion in a skilled group is much better for learning—and, surprise, that’s what an ensemble is.

Conclusion

As codebases grow, the way we work with them needs to evolve. Working in parallel speeds development on a greenfield project, but as the system expands, communication costs outpace productivity. We need to get everyone together to work on the next feature, one feature at a time. We will deliver software faster. There are other benefits, like building better software and building the team’s capacity, which I’ll discuss in separate issues. But the main advantage is an increased team throughput.

We’ve been cracking the whip on code and documentation quality for too long. These only put more burden on the overworked engineers. It hasn’t worked. There are companies out there ensemble programming. They like it! I am fully expecting companies that ensemble to outcompete those that don’t, and it will be apparent to all that the industry needs to change. The question is how long it will take you to switch.