I’m thinking about developer productivity.

Developer productivity is a hot topic right now. It’s a topic that inspires many different ideas, approaches, perspectives, and research: McKinsey, Response to McKinsey, SPACE, DevEx, Google. One conclusion we can probably all agree on is that modeling developer productivity is hard.

Some time ago, the podcast Planet Money created an episode in which they asked the question, “What’s the most useful idea in economics?” to several prominent economists, resulting in five different answers. Can we use these five ideas as a lens through which we can look at developer productivity? Will it help us improve how we think about modeling developer productivity? Let’s explore.

When I think about software development activities and their opportunity costs, I think of the choices we make on a product level. A development team can be very productive in terms of output, e.g., delivering several features quickly. But how valuable are these activities? Could the time spent on these activities have been spent developing more valuable features to achieve a more beneficial product goal? When we try to model developer productivity, should we also consider product management efficacy?

If we model developer productivity in terms of output, we clearly can’t say much about the value of the work. Even if we see an increase in output, that doesn’t imply an increase in value. Using measurements of product-level outcomes in our productivity model is an improvement and can offer relative changes in outcomes over time. But should we add another dimension to our model to offset outcomes against outcome potential?

Recently, I read Kent Beck’s book “Tidy First?“, which I highly recommend. The book thoroughly discusses the economics of tidying code. When it comes to marginal analysis, I was reminded of a specific question Beck poses:

“How much tidying do you need to do? That is, if we define ‘tidying’ as structural changes supporting the next behavior change, then how many structural changes do you need to make to support the next behavior change?” [1]

In my experience, it is all too common for development teams to skimp on their tidying efforts, manifesting in ever-increasing cycle times for feature development, forcing teams to plan big and risky refactorings. When we try to model developer productivity, how can we account for the incremental choices supporting behavior changes with structural changes? Should we include the development organization’s ability to stabilize the cost of behavior change and associate it with the costs of structural changes? But how well can we differentiate between the two types of changes?

Let’s consider the most senior person in a development team; that one person with intricate knowledge of and experience working on the software. Regarding measurable outcomes, seniors might be most effective in completing feature development by themselves. However, seniors are also best suited to guide the team, e.g., by mentoring juniors and helping onboard new joiners. The average efficacy of a team member can be higher if the more experienced people make time to enable their team members instead of focusing just on their own output.

In our model of developer productivity, how can we account for the distribution of knowledge and experience in a team or organization? Should we include mastery as a dimension of developer productivity next to product outcomes in our model? How do different dimensions in our model relate or compare to each other? Does an increase in mastery, the total knowledge and experience level of a team, imply an increase in product outcomes?

In a software development organization, the activities are constantly changing. Some manual tasks are automated. GenAI tools provide instant feedback. Low code replaces some code. These changes impact productivity in whatever way we have modeled it. A decrease in activity might be localized when, specifically, the activities in one area are changing or disappearing altogether. This localized decrease doesn’t imply they’re doing a worse job; it might mean the nature of their job is changing, and time is needed to evolve.

Can we model developer productivity with enough context to avoid taking away the wrong conclusions? Should a model include a dimension to show how much a team or organization is in flux? Should adapting to change itself be a part of our model for developer productivity?

Software development organizations are complex systems. There are several examples of organizations gathering lots of data to get an idea of how such a system works, like Google’s “Project Aristotle.” And we can get worthwhile insights from research like that. However, there are no randomized or natural experiments to show some kind of causality.

Whatever model for developer productivity we choose, we must realize that we are not modeling cause and effect. Our model and the data we gather to query it can give us insights and show correlations. It can trigger us to run certain experiments and observe the impacts. It can point us to areas that might be problematic and need further exploring. It can not show us a precise reason for a particular outcome.

When modeling any problem space, I remind myself of the meaning of the word model with words by Eric Evans:

“A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignoring extraneous detail.” [2]

What problem are you trying to solve with your model for developer productivity?

Quotes

• [1]: Beck, K. (2023). Tidy First? “O’Reilly Media, Inc.” (p. 43)
• [2]: Evans, E. (2004). Domain-Driven Design: Tackling Complexity in the Heart of Software “Addison-Wesley” (p. 2)
• All other quotes are from the NPR’s Planet Money episode “13,000 Economists. 1 Question.” published on January 10th, 2020.

This blog is part of our series “Holistic Horizons“. Check out the previous entry – “Value Stream Mapping for earlier confidence” by Lennart Tange.