Maximizing Your Development Team's Potential Through Automation
Written on
Chapter 1: Understanding Automation's Impact
What if increasing the number of developers could lead to more than just a proportional increase in their output? Is such a scenario feasible?
In a previous article, I highlighted how the lack of automation often proves to be more expensive than anticipated:
Exploring Capacity Beyond Team Size
Is it possible to enhance a team's effectiveness without simply adding more members? Initially, I doubted this in the context of software development until I read "Accelerate" by Nicole Forsgren and others. They assert that companies that implement the right technical practices and architecture can reverse conventional wisdom: increasing team size can lead to greater productivity per individual. They illustrate this concept with the following chart:
The chart from "Accelerate" demonstrates that high-performing teams can achieve exponential performance increases as they expand.
When we juxtapose Robert C. Martin's insights with those from "Accelerate," we observe a spectrum of expectations. Typically, we hope to maintain each member's productivity as new members join. However, what factors contribute to the detrimental effects of adding team members? How can we boost individual productivity as teams grow?
Modeling the Problem
To grasp this scenario better, let’s look at a comparable phenomenon observed in supercomputing. While not identical, it shares relevant characteristics and has been extensively analyzed.
In supercomputing, three types of scalability are identified based on how adding more processors impacts execution speed:
- Parallel Slowdown: This occurs when increasing the number of processors leads to slower speeds due to excessive communication overhead.
- Embarrassingly Parallel: These are ideal problems that can be distributed across multiple processors with minimal communication, resulting in faster execution.
- Superlinear Scalability: In this case, doubling the processors can yield outputs that are four, eight, or even sixteen times faster, provided the working memory fits entirely in the cache.
Thus, the balance between processing power and communication overhead is crucial. The more communication required by a program, the less scalable it becomes.
Connecting the Analogy to Software Development
Drawing an analogy, we can liken processors to developers and programs to features. More communication leads to slower development. Therefore, the key to maximizing scalability lies in minimizing communication requirements among developers.
One of the most significant factors affecting development time is the reduction of handoffs. For instance, consider the following illustration from SAFe:
This diagram illustrates that eleven hours of work can stretch over nearly two months due to handoffs. Many of these steps could be automated in a trustworthy environment. For example, the “Approve” step might be unnecessary for short tasks, while the “Technical Assessment” might stem from poor architectural choices. With the right automation and testing strategies, we could save substantial time and enhance team productivity.
Robert C. Martin emphasizes that increasing team size can slow down productivity, but this is not simply due to the size increase itself. Instead, it’s about the hidden communication challenges stemming from the code. Programmers communicate through both conversation and code. Messy code complicates understanding and hampers productivity, thus affecting the entire team.
Achieving Team Superscalability
When can we anticipate superlinear scalability within development teams? Consider the following conditions:
- Automated Delivery: We achieve a seamless continuous delivery process, allowing rapid transitions from ideas to deployment, thereby lessening communication gaps.
- Clean Code: New developers maintain high code quality. With low coupling and readable code, they can write new features with minimal time spent revisiting existing code.
In this analogy, reducing the need for processor-to-memory access equates to minimizing cognitive load. If tasks are straightforward, code is clean, and testing is efficient, developers can focus on their work without unnecessary distractions.
Validate the Insights
Don’t take my word for it, or even the words from the authors of "Accelerate." Test it for yourself.
If you have at least two developers, you don’t need to hire more to validate this hypothesis. Assess your processes, identify handoffs to eliminate, automate as many steps as possible, encourage cleaner code practices, and adopt techniques similar to BDD. Start with small, continuous improvements and observe how efficiency accelerates over time.
Thank you for reading! If you enjoyed this article, check out my most popular stories on Medium for more insights.