Why most software teams are inefficient

Uncovering the main reason for inefficiency in software teams and how to boost productivity significantly

The biggest myth

The biggest myth in the software industry is that developers should work alone. Every time we see a coder in a film or a photo, that person geeks alone. The software industry treats software engineering as a loner activity. People are taught to work in isolation, with async communication, which is the least efficient way to produce quality software. Yet, it has become the standard way to build software in the 21st century—a sad reality.

To be upfront with you: I love being in the flow, sitting alone in front of my workstation, putting my headset on, listening to my favorite music, and implementing some cool stuff with my favorite programming language. Being into the tunnel while being both undistracted and pumped. Many of us can relate. However, the effectiveness of this way of working is far from what a team could achieve with other collaboration techniques.

Working in isolation is slow. It is unproductive. It leads to inefficient communication patterns. To achieve collaboration, we must find ways to talk to each other asynchronously. To mitigate this, the industry has invented and utilized feature branches. We communicate and share knowledge via Pull Request (PR) code reviews. However, feature branches turned out to be the main bottlenecks of teams. They tend to be superficial, create blockers, and result in long lead times.

If you want to know more about why Pull Request reviews are one of the disasters of our industry, check out my previous post.

Working in isolation also comes with poor knowledge-sharing practices. When we work in isolation, all of us are sitting on a ton of knowledge that can’t be just shared with code and PRs. We should find a way to share implicit knowledge and intents, design decisions and reasoning, or even share general knowledge regarding crafting quality software. On top of that, a healthy software team should continuously strive for technical excellence, meaning that there is always something new to learn and share with colleagues. We can’t do these efficiently with Pull Requests.

Sharing knowledge on other communication channels like Discord or Slack is also not ideal. They might be OK to ask questions and get some answers. However, such convos can quickly turn into long-lasting async ping-pong-styled communication, which takes a lot of time. Time is money. More time also means a longer lead time. It should be in our best interest to keep both as low as possible.

Writing comprehensive documentation on wiki pages is also a common approach to sharing knowledge, but it also has its downsides. Every documentation is a tech debt. We have to continuously maintain and update them. Sooner or later they become outdated and nobody will read them. So it is better to minimize them to the absolutely necessary knowledge instead of using it as a go-to medium of information exchange.

Solution 1: two heads

First and foremost, people should understand that software engineering is not about typing. It is about thinking. It is about finding the most efficient solution for the problem domain. A handful of collaborators working together think more effectively, they solve problems faster and realize solutions better than individuals working in isolation.

One of the most common ways to efficiently collaborate together is to use Pair Programming. It is the most underrated practice within software development. Two heads are better than one. By practicing it, we end up making fewer coding mistakes, having better quality, and doing continuous knowledge sharing. It makes decisions easier and coding more fun. It is beneficial both for the code and for the people.

Within Pair Programming, two individuals form a pair in front of the same work machine while having the same goal. It follows the driver-navigator model. The driver is one who sits at the keyboard and writes the code, the navigator is the one who reviews the code and proposes solutions to the given problem. Although the roles can be mingled, the driver-navigator separation is still recommended to get the most out of both parties. It will give equal voices to both individuals, resulting in a powerful and productive pair.

Solution 2: the whole team approach

There is an even better way to maximize productivity. It is called Mob Programming. Mob Programming is Pair Programming on steroids. One driver, multiple navigators. It is a whole team approach. I find the following quote the most expressive one to describe Mob Programming, coming from its inventor:

All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer - Woody Zuill

With both Pair and Mob Programming, we can easily fix all the problems of the isolated way of working:

• Reduced context-switches: by closely working together we significantly reduce work in progress (WIP), letting us focus only on the most important tasks, together, one by one, resulting in much fewer context switches. Context switches are one of the main productivity killers in software development, so minimizing them should be our highest priority;

• Sync over async communication: when we work together, there are no reasons to use Pull Requests and their slow review processes. We continuously and synchronously review the code we work on. No more waiting for others, no more bottlenecks by to-be-reviewed PRs, and no more ping-pong-styled communication;

• Improved knowledge sharing: every team member follows the same mental process, everyone knows the reasoning behind the code changes and everyone is up to date with all the information related to the software project. We learn and improve together while working in synergy.

Within Mob Programming, any support happens instantly, synchronously, and right at the time we need it. No more waiting, no more blockers, and no more misunderstandings, resulting in shorter lead times. A short lead time is a requirement for continuous delivery. Continuous delivery is a requirement for being agile. Agility is the foundation for providing value to our customers and making them happy. This is our most important goal. Everything else is noise.

Both Pair and Mob programming come with a lot of social aspects. We are socializing all day. Human beings are social creatures. Working together can harness the power of unity to unleash limitless potential. They create a synergy between us. A synergy that a team can never achieve by having their members working in silos. I never met a team who started using Pair or Mob Programming, then got back to the isolated way of working. Never! They are the silver bullets of successful collaboration in software development.

One person can only do the best work that person can do. When the whole team works on the story as an ensemble, you get the best work the entire team can do. - Allen Holub

Bonus session

This week, I had the honor of welcoming a star speaker to our Software Crafters Twitter space: Woody Zuill, the inventor of Mob Programming. Woody is the epitome of kindness and expertise when it comes to software collaboration. During the session, we discussed Mob Programming and its potential to help produce high-quality software. You can replay the recording at your convenience by clicking the link below. Enjoy!

Daniel Moka⚡ @dmokafa

https://t.co/Oma2i2MWqu