Efficiency and Effectiveness in Software Development Teams
Efficiency and effectiveness. These two concepts are quite often mixed up. Each with their own strengths and weaknesses. Understanding these concepts will increase the impact of a software developers work.
They come to play in the following quote from former Apple CEO, Gil Amelio who said:
Amelio: “Apple is like a ship with a hole in the bottom, leaking water, and my job is to get the ship pointed in the right direction.”
Smith/Jobs: “But what about the hole?”
Before we take apart that quote, let’s dig into some definitions!
Efficiency: Doing the thing right
Effectiveness: Doing the right thing!
Amelio is focusing on doing the thing right: “…get the ship pointed in the right direction“. But he isn’t focused on doing the right thing: “But what about the hole?“. So he’s focusing on efficiency, and not effectiveness.
Now that we have a grasp of the concepts, let’s look at how this maps over to he realm of software development teams.
As a single developer, working in a team (or alone). It’s easy to get caught up in a cycle of efficiency. Where the mindset and focus is on getting yourself up to a high level of productivity. Such as streamlining how you write code through patterns, practices and looking for repeatable processes. It could also mean having a strong focus on writing quality code. There may also be a tendency to take this too far and optimise code for terseness and not readability..
The cycle of effectiveness entails more pragmatism and being aware of your context. An effective developer understands the context of the tasks they are working on. They are then able to make decisions in code based on that context. Such as when and how to make compromises when it comes to code quality / abstractions and implementation details. Sometimes whats needed is to take a step back and solve problems without code. Or even removing features.
Pair & Mob Programming
Most developers have heard of the concept of pair-programming, and even mob-programming. Both are considered as good practices for many reasons. At the same time these practices are also scorned upon by others as inefficient and a waste of time.
Pair-Programming involves 2 people (dev, tester, business etc) working on the same screen. There are many variants, including strong-pairing, driver /navigator, TDD-driven variants and some others. Eric Elliot has a great breakdown on pair-programming styles.
Mob-Programming is an approach that involves the entire team working on the same screen, and delivering the code in a similar way. The recommended approach is a driver / navigator style where the team serves as navigator and the driver writes what the navigators tell them. I wrote a little about it here.
These approaches sound wasteful and inefficient, especially mob-programming. Yet people argue that these are great way to deliver more value by being more effective. Why? How?
The premise is more eyes on the code written, more knowledge sharing, and a shared sense of ownership. There’s also a cross-pollination of disciplines, ideas and shared ownership. Understanding others’ limitations and strengths will allow a team to grow even more.
The fundamental drive for these approaches is about being more effective.
Slack and the Utillisation Trap
Henrik Kniberg has produced many articles and videos about the balancing act of delivering value through teams. He’s presented two concepts that illustrate the power of an effective mindset; Slack and the Utilisation Trap.
Slack is the absence of work. Where people have the opportunity to decide how they want to spend their time for themselves. What may seem counter-intuitive is how much value there is in unplanned time. The idea is that this is where people have the opportunity to “do magic” or innovate. Basically, being effective. Check out Henrik’s video on the topic.
The Utilisation Trap relates to slack. It depicts the notion of achieving a highly efficient team, which always has work to do. The focus is to achieve as close to 100% utilised as possible. By lowering the efficiency rate and introducing slack a team can achieve an optimal state of flow. Here’s Henrik’s video.
Organisations and development processes tend to have a focus on how efficiency in their systems. So it’s very natural to get stuck in a mindset of efficiency, when what you want is effectiveness. In the rush to be over-effective, it’s also easy to bypass efficiency, leading to poorer systems.
Focusing on efficiency alone can lead to poor solutions that don’t meet the needs of our systems. Focusing on effectiveness alone can lead to inefficient systems that are technically flawed.
As I have grown and evolved as a person and a developer I’ve felt that my maturity / seniority level matches my focus on effectiveness. In my younger days, it was all about being as efficient as possible, where now I’m focused on being as effective as possible. As I further progress, understanding where and how to be both efficient and effective is where there is the most value. Growing a proactive mindset has been a way for me to realise my impact in the greater context.
As earlier stated in this article, both are valuable, but there’s a natural tendency to lean towards efficiency. Instead we should spend more time on practices that make us more effective. As developers, teams and organisations.