DevEx & A New Way To Measure Developer Productivity
A Thread on Developer Productivity And Empowering Teams
Reddit is excellent for quickly collecting public opinion and trying out ideas without having thousands of followers to reach out to. I shared a link to a research paper and threw out a question in one of many developer community threads, and I got some fascinating reflections.
My first post ever on Reddit!
DevEx: What Actually Drives Productivity
by u/nimblegeek in programming
I was curious to know more about other developers’ experience of measuring productivity.
This is an area that gathers many practitioners, from product managers to developers and designers. Different emotions, experiences, opinions, and insightful comments poured out from this thread.
The post gained traction:
From skeptics to enthusiasts, I collected different views on why and how to measure the parts big organizations struggle with.
My main goal with this question was to understand more what other practitioners in tech think since my experience is that most of the metrics, frameworks, and tools in software development have been mistreated and gamified to reach some arbitrary goals. For example, I once worked in a setting where developers’ compensation was tied to the number of story points completed in Jira. I am still trying to recover from that.
Before we proceed with the published paper and the DevEx - thread, let’s have a quick glance on some traditional ways companies have measured developer productivity through the years.
Different Industry Standards on How to Measure Developer Productivity
Lines of code: One of the most common ways to measure developer productivity is by counting the number of lines of code they produce. However, this method can be flawed as it doesn't take into account the quality of the code produced.
Bug count: Another way to measure developer productivity is by counting the number of bugs they fix. However, this method can also be flawed as it doesn't take into account the complexity of the bugs.
Velocity: Velocity is a measure of how much work a team can complete in a given time period. It is calculated by summing up the story points or number of stories completed in a sprint.
Cycle time: Cycle time is the time it takes from when a task is started to when it is completed. This measure can be used to identify bottlenecks and improve team productivity.
Code review feedback: Measuring the feedback a developer receives during code reviews can be a good indicator of their productivity. A developer who consistently receives positive feedback is likely producing high-quality code.
Customer satisfaction: Ultimately, the success of a project depends on whether it meets the needs of its users. Therefore, measuring customer satisfaction can be a good way to assess developer productivity.
You have probably used a few of the above in your own team. My stance is that as soon as you get transactional and start measuring things like lines of code and numbers of stories, you lose your true focus. No matter how great of a product you have. You will end up in a rabbit hole.
Through my years as a scrum master, my experience is that as soon as you bring up a metric that is not aligned, decided and discussed with the developers and the team, you will not be able to build an empowered team.
The metric will only be interpreted as a way to micromanage a developers day to day work in most cases.
Now, back to the Reddit thread.
The link I shared was about new framework for developer experience that I found interesting, mainly because it covers a human developer perspective and team empowerment, not an industrialized, tayloristic mindset.
What caught my attention was the combination of the below three dimensions:
Flow state - Our ability to find focus. A mental state in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment.
Feedback loops - the speed and quality of responses to actions performed.
Cognitive load - the mental processing required for a developer to perform a task.
Overall, a refreshing perspective, right?
The question is how companies would implement it in practice. How can this model applied In the trenches, out there in the teams working with solving business problems with software solutions? Meaning how do we avoid standing there with yet another paper product that doesn’t support the developer’s daily work?
Will this be used as yet another way to gamify the system, or will it improve a team's productivity?
To understand more, the research paper pointed out a suggestion on WHAT to measure:
A decent DevEx metric. Not too complex and has enough specificity to enable great team discussions.
A refreshing addition to established frameworks out there, such as Scrum, Kanban and SAFe which all tries to achieve similar goals such as CI/CD and boosting the DevOps capacity.
I believe in working with a data-driven approach. But data is also easily manipulated. So it would be interesting to see how teams can tie each area's perceptions and experienced satisfaction to the data collected.
Overall, I think this paper is interesting to bring up for discussion in your respective team and I would recommend treating it as such—a basis for co-creating a relevant setup for your team.
After all, the purpose should be to find out what works best for your team without being tempted to measure things for measuring's sake. We all need to understand WHY we measure what we measure.
Finally, here is my honest opinion on developer productivity, metrics, and frameworks:
We all need to differentiate between means and goals. Be honest with what your actual goals are, and be careful with the standards of how to reach those goals. A metric is never a goal. It is a helpful indicator of where you are and gives input for how you can learn more about the best way to move forward.
Most of us don’t want to overcomplicate things. We want to work with meaningful things, one piece at a time, without too many distractions. And there is nothing wrong with working hard from time to time.
Let me know your experiences and thoughts, and feel free to like and share them below.
With that in mind, I wish you all a productive week ahead!