RDEL #5: Software Engineering Productivity: How do you define it? (Part I)
In this two-part series, we'll discuss how to define and measure productivity from the lens of the researchers.
Good morning, and welcome back to Research-Driven Engineering Leadership! Each Monday, we pose an interesting topic in engineering leadership, and apply the latest research in the field to drive to an answer. Before we dive in - I want to send a sincere thank you for the exceptional response to our first four editions. It’s been a joy to learn that folks are already taking our research-backed insights and applying them to their teams. Music to our ears! 🎉
For the next two weeks, we’ll be doing a deep dive into what software engineering productivity is, and how you measure it. This week, we take a closer look at the term “productivity” as it applies to engineers - how do you really define it?
The context:
Software engineering productivity has been long-debated by researchers and practitioners. The simplest definition of “productivity” is output divided by input. Whereas computer systems can be measured in a more objective manner, humans building software poses a much more difficult challenge. There are interpersonal dynamics and intellectual work, which means that both output and input are not straightforward to measure.
We’ll look at the definition of software developer productivity, using an integrated model.
The research:
Stefan Wagner and Florian Deissenboeck defined productivity in a software context in the book “Rethinking Productivity in Software Engineering”, edited by Thomas Zimmerman and Caitlin Sadowski. The researchers begin their analysis be defining a few important terms in both the inputs and outputs of productivity.
Efficiency: The utilization of resources, which mainly influences the required input of the product. (”doing things right”).
Effectiveness: The usefulness and appropriateness of the output (”doing the right things”).
Quality: the degree of excellence of the work, which is critical for evaluating the output of knowledge work.
Using these definitions, the researchers create the following model of productivity:
Some notable details:
Everything starts from a given purpose - what is the team trying to achieve?
Inputs are driven by how efficient things are, or the level of effort (in yellow)
Outputs are driven by effectiveness, which takes into account the produced functionality and quality.
In the end, it all boils down to outputs divided by inputs to create a model for productivity.
The application:
Researchers show that productivity is the combination of effectiveness and efficiency - a team can only be productive if it is both efficient and effective. A team that builds many low-quality features is not effective, therefore not productive. Conversely, a team that spends an unnecessary amount of effort to build a feature is not efficient, therefore also not productive.
For engineering leaders considering how to measure productivity, start with the basics. You need to measure efficiency of what your team puts in, and the effectiveness (including quality) of what your team produces. Without an accurate estimate of both dimensions, you won’t have the full picture of how productive your team is.
So now we know how to define productivity, but how do you measure a team’s productivity? Next week, we’ll cover the framework(s) you need to know to measure your team’s productivity.
—
Wishing y’all a great week.
Lizzie
From the Quotient team