We are thrilled to announce 📢 Kosli is now SOC 2 Type 2 compliant - Read more
New Feature: Kosli Trails is liveCreate comprehensive audit trails for any DevOps activity - Read more
Kosli devops change management ensemble programming

8 reasons why we do ensemble programming

Mike Long
Author Mike Long
Published December 14, 2021 in culture, technology
clock icon 7 min read

At Kosli we do as much of our work as possible in a group setting, especially (but not limited to) programming. In our experience most tech teams don’t do this and we think they’re missing out on all kinds of advantages that come from working as an ensemble. In this post we’ll share why we do ensemble work, what our experience has been, and why we think you should give it a go.

1. Culture is built one conversation at a time

We think a lot about our team culture at Kosli. We’re a startup, so we’re building a company as well as a product and that requires a strong culture. For us that means being deliberate about how we collaborate, communicate, and make decisions.

As a company formed in the middle of the covid pandemic we have been remote-first from day one. Fostering a common culture that doesn’t involve water coolers, team off-sites, and shared lunches can be a challenge. First and foremost it requires trust.

We’ve found that frequent, positive interactions as an ensemble has made it easier to build trust and discover shared values.

2. None of us is as good as all of us

There is a common saying in the ensemble programming community that “none of us is as good as all of us”. On any given task individuals can have good or bad days. We can also have strong skills or weak skills. We can have deep or shallow expertise. By working together we can realize the full potential of everyone’s abilities. The best of the whole team makes it into every decision.

graph showing quality of work when whole team works together at Kosli

Figuring out how to meet our customers needs, understanding the tradeoffs on solutions, and prioritizing and engineering work are all hard problems.

We want to make sure we optimize for great decisions and ensemble approaches ensure we bring our collective intelligence to every task. As the saying goes, “many eyes make all bugs shallow”.

There’s also a performative aspect to a group setting - we all want to be the best version of ourselves. This helps us avoid shortcuts and quick fixes.

Programming in a shared setting is also a form of continuous code review. This makes it easier to set collective expectations, so everyone knows what’s expected - even if you’ve only just walked in the door.

And, if you know what the rest of the team expects, you know what you have to do to start contributing. That takes a lot longer when everyone is coding on their own.

3. Knowledge production is our biggest bottleneck

As a startup, we are starting from a blank slate. We are exploring new and better ways to solve compliance and change management and there is no existing solution to copy. In this area of software development we are facing a complete absence of good solutions.

To overcome this we have to create new ideas, strengthen them, realize them, and then test them in the market. These innovation loops are completed much faster when we work together to explore a wide array of possibilities.

4. Specialization is for insects

For us, most features are full stack problems. To deliver on customer needs we often need to code across our client, our backend, our data, and our user interface.

If our team was composed of specialists for different parts of the stack it would mean a lot of wait states, handovers, and miscommunication. It would also make testing a big challenge.

By committing to single piece flow, we share competence and knowledge across the team and that makes everyone confident in all areas of the codebase and with all our tools.

This in turn establishes collective ownership of the codebase.

5. Chasing the Continuous Improvement dragon

We all know that it is better to work smarter than to work harder, but things don’t improve by themselves. It requires a culture of support and pressure to improve capability.

continuous improvement loop kosli

One of the fantastic things about mob programming is that everyone sees and experiences the same things. So, if tests are slow to run, if the logging is noisy, if the design is clunky, we all feel it together. And this collective pain drives us to fix things.

The counterpoint is also true. As we fix problems and remove pain, we share the joy from these benefits. This leads to a virtuous cycle of agency because we gain motivation and empowerment from the results.

6. Bulldozers and racecars

The biggest criticisms we’ve seen of ensemble programming revolve around efficiency concerns. Wouldn’t it be more effective to parallelize the work?

We believe software development is not a MapReduce problem, i.e. it isn’t compatible with top down decomposition, farming out tasks to worker bees, then integrating the results. Parallelism works great for piece work, but teamwork works best for knowledge work.

Contrary to popular belief, typing is not the bottleneck when it comes to software development. By far the biggest cause of delays is wait states and lack of inspiration. We want to optimize for quality of decisions over quantity of decisions.

By working together we significantly reduce the likelihood of getting stuck and we don’t have to wait for help.

One of the challenges of growing a technical team is how to onboard new members without impacting our momentum. As Ewelina discussed in a previous blog, mob programming - even remotely - enables new employees to become productive members of the team within a few days. This is what Jeff Langr means when he’s talking about busting Brooks’s Law. This also makes it easier to bring in specialist consultants in a productive manner.

7. Less chance of burn out

Knowledge work is emotional labor. We need to manage our emotions and support ourselves and our team as we do our work. And this labor comes at a cost.

The practices in ensemble work make this easier to handle. For instance, if we are feeling overwhelmed it is easy to swap roles or even check out altogether if that’s what’s needed. It also reduces task switching because the work continues even if we don’t.

We also reduce the individual pressure to deliver since we share the responsibility for success. This is the basis for the psychological safety we believe we need to win as a team.

8. It’s more fun!

Last but not least: it is a lot more fun to work together to solve problems. We have a weird image in software that it is an individual, isolated endeavor. And in many places it is. But we knew this wasn’t the case as far back as 1971:

We must deal with one other problem, which is important because of a seldom questioned view of programming - a view which this book will spend a great deal of time questioning. That view is that programming is an individual activity.

Jerry Weinberg

We’re on team Jerry!

Summary

We’ve found ensemble approaches work for all types of tasks: customer success, coding, design, testing. Anything that requires thought, really. And isn’t that the type of work we all want to be doing?

We’ve had a great experience doing ensemble work this year as we grew from 2 employees to 12. How will it scale? How will we adapt our practices as our team matures? I’m sure we’ll figure it out together!


ABOUT THIS ARTICLE

Published December 14, 2021, in culture, technology

AUTHOR

Stay in the loop with the Kosli newsletter

Get the latest updates, tutorials, news and more, delivered right to your inbox
Kosli is committed to protecting and respecting your privacy. By submitting this newsletter request, I consent to Kosli sending me marketing communications via email. I may opt out at any time. For information about our privacy practices, please visit Kosli's privacy policy.
Kosli team reading the newsletter

Got a question about Kosli?

We’re here to help, our customers range from larges fintechs, medtechs and regulated business all looking to streamline their DevOps audit trails

Contact us
Developers using Kosli