Working in an ensemble enables us to produce higher quality code, share knowledge, onboard new team members faster, and ultimately helps us to build a stronger culture. 

What is ensemble programming?

Before we get to a definition, let’s highlight the main characterization of an ensemble.

Ensembling can be categorized as a method of collaborating in real-time among small teams of developers. Teams practicing ensemble programming perform most of the tasks of a typical software development team including designing, testing, deploying software, and more. This approach takes advantage of a group’s collective knowledge and focuses it on one single task.

This definition seems straightforward enough, but what does this look like in practice – especially when you’re a remote-first team? 

Ensemble programming as a remote-first team

Being a part of a distributed team can be challenging. Using platforms like Google Meet and Slack can be a helpful way for ensembles to communicate and ease the hurdles of remote working. 

In our organization, we have a Slack channel called “beta” with a link to a Google Meet address pinned at the top. When we join for a session, someone shares their screen and brings up the terminal (we call this “taking turns to drive”). We then work through whatever code we’re trying to write and everyone is free to make suggestions. 

What typically happens is that someone shares an idea, others chime in with how to tweak it to make it better, and whoever is “driving” types the combined output of all our efforts. It happens faster than you’d think and we benefit from instant feedback with real-time code review. It’s also great for knowledge sharing and gives new team members the opportunity to shine. 

Why is ensemble programming not more commonly practiced?

There are several reasons why ensembles may be the exception rather than the norm when it comes to software development. 

Challenges of ensemble programming and how to overcome them 

1. Challenge: What’s the number one thing developers complain about? Meetings! And for a lot of people, ensembles kind of sound like another meeting to add to the list.
   
   Solution: developers may hate meetings, but software delivery processes cannot run if everyone works alone and no one talks. Communication is required for team alignment, so why not replace at least some of your meetings with an ensemble and actually write a bit of code while you're talking?
    
2. Challenge: there’s a perception that working in an ensemble is wasteful. If you’re in a managerial role and you’re being evaluated according to a developer productivity metric, having several people working on one thing probably isn’t going to appeal as an approach.
   
   Solution: wouldn’t you rather catch bugs immediately and do fewer code reviews? Don’t you prefer solving problems now rather than later? We hear a lot about the mythical 10x developer, someone capable of doing heroic amounts of work on their own, but what about the unrealized potential of more effective teamwork? You could have three people sitting next to each other who are capable of instantly solving each other's problems. But this hasn’t come to pass, instead, your team is searching Stack Overflow. 
    
3. Challenge: even if there’s buy-in from developers and management, ensembling presents an immediate cultural challenge that can be off-putting. The nature of ensembling calls for the immediate resolution of differing opinions, all out in the open. This approach requires everyone on the team to be aligned on common goals. In organizations where this isn’t the cultural norm, it’s easy to hide behind pull requests (PRs). 
   
   Solution: if setting expectations and finding a way to collaborate at the same time are barriers, then you have deeper problems in your organization that need to be addressed. Maybe an ensemble session would be a good way to start working through them?

The benefits of programming as an ensemble

The most effective way to overcome objections to ensemble programming, especially those held by skeptical managers, is to emphasize the benefits. 

In our experience, working as an ensemble simply produces better code right from the start. It’s also more efficient. Bringing our collective skills and experience to each problem means that we are able to work out our strongest solution. We’re also able to go through faster feedback loops where bad ideas don’t live for very long. It all adds up to fewer bugs, PRs, code reviews, and other troubles that come from shipping low-quality code written in a silo. 

What’s even more beneficial is the pooling of knowledge and resources. Coding in an ensemble means that we always benefit from the best expertise on the team – and that expertise is then shared out in the open. As we like to say, “None of us is as good as all of us.” This method is also great for onboarding new team members who can learn and contribute much faster than if they were trying to work things out on their own. 

This pooling of resources has another positive side-effect – everyone feels included in the development process, benefits from the same knowledge, and shares ownership of the codebase. People like to feel that they’re a part of something, which is good for staff retention. By doing this, you also decrease your lottery factor. 

Building a strong culture with DEI at the center

How software is delivered and what that software looks like says everything about the organization that made it. Ultimately, we ship our culture. So, if we’re at all serious about delivering the highest quality code that draws on the best of all our talents, why wouldn’t we opt for an ensemble approach?

Diversity, equity, and inclusion (DEI) is an important, often-talked-about topic. But as many of us know from experience, that talk doesn’t always translate into action. We need to do more than change the social media avatar when it’s Black History Month or Pride.

With ensembles, you can promote genuine DEI initiatives by embedding them in the way you work. For example, depending on the tasks we have in front of us, sometimes it makes sense to break out into smaller ensembles and pairs. Working on real problems in groups of two or three is an excellent opportunity for mentoring and targeted development of underrepresented groups. Not only will people feel like they are making a real contribution through ensemble programming, but it will also give them an opportunity to upskill and learn. 

Final thoughts

Ensemble programming can be at the center of a holistic approach for your whole organization, the people inside it, and the products they make. With ensembles, you can build a strong development culture of continuous improvement where people feel valued, do their best work, and deliver quality code every day.