Productivity is a concept we all wrestle with as developers in a world that increasingly demands that we do, code, debug, unit test, learn, ingest, and integrate more.
The operative word here is “more.” What we don’t have more of is time.
So how do we get it all done without sacrificing quality?
The short answer: it’s not easy. But fortunately, we have devtools, research, and our own experiences and instincts as developers to push forward the conversation about productivity on R&D teams.
What is developer productivity?
Trust us – coming up with a meaningful working definition of developer productivity is more challenging than you might think.
The concept of productivity grew out of the manufacturing sector and can be defined as “a term used to measure the performance of a process where the output from continuous improvement becomes more efficient.”
The problem with this definition: manufacturing organizations produce large quantities of identical items; not so for software development organizations.
So, while IT has borrowed the concept of productivity from manufacturing, it is infinitely more difficult to define and measure in a software development context.
Why is developer productivity so difficult to measure?
The business world is one of measurement and metrics, and software development is no different.
So, to define developer productivity, many organizations simply identify the development metrics they want to track and then compute what is considered an acceptable baseline. Next, they measure a developer’s performance against this baseline to assess their performance. As a result, developers are often put in a difficult position – their qualitative performance is measured by quantitative metrics.
Let’s be clear: we’re not saying that quantitative measures don’t have their place. But defining productivity based on KPIs to the exclusion (or almost exclusion) of qualitative context is misleading.
Metrics: a problematic method for measuring developer productivity
The metric used to measure developer productivity – lines of code written (LOC) – is fraught with problems.
First, can you imagine developers knowing they are being evaluated based on LOC? Measuring developer productivity using the LOC metric fails to consider qualitative factors such as the stage of development, the amount of existing technical debt, the complexity of the bug fixed or functionality created, the coding language used, etc. Moreover, it disincentivizes developers from spending time on testing and debugging since these activities don’t necessarily directly result in lines of code. Of course, many times, the best solution to a programming challenge involves very few lines of additional code – but still requires a lot of time and thought.
Similar issues arise from other qualitative metrics such as hours worked, code reviews completed, commits to Git, bugs fixed, tickets resolved, number of features, number of releases, number of user stories, or story points.
The list goes on and on.
Using standard metrics-based measures of developer productivity promotes developer burnout, increases employee turnover, and ultimately damages the organization.
So, are there better ways to measure developer productivity?
R&D managers have begun to recognize that developer productivity is more accurately measured by business outcomes than performance outputs. This recognition has led to more contemporary models and frameworks for measuring productivity.
Developer velocity
In 2020, McKinsey & Company coined the term Developer Velocity. Developer Velocity is not just about speed but also about unleashing the full potential of developers. Tools, product management, culture, and talent management have the most significant impact on Developer Velocity and business performance.
SPACE
Taking this idea one step closer to practical implementation, researchers from GitHub, Microsoft, and the University of Victoria published a detailed paper about developer productivity.
A framework they named “SPACE” captures different dimensions of productivity using measurement metrics with important context:
S – Satisfaction and Well-being: How fulfilled developers feel with their work, team, tools, or culture; how healthy and happy they are, and how their work impacts it.
P – Performance: The outcome of a developer’s work – which can admittedly be difficult to measure because business outcomes often can’t be drawn directly back to developer output.
A – Activity: A count of a developer’s actions or outputs completed while working.
C – Communication and Collaboration: How people and teams communicate and work together. Software development is a collaborative and creative task that relies on extensive and effective communication, coordination, and collaboration within and between teams.
E – Efficiency and Flow: The developer’s ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system.
Team-based measurement
Software development is a collaborative process, and therefore there is value in assessing developer productivity at the team level rather than the individual developer level.
First, team members have different roles and tasks, so individual productivity metrics are often not generally applicable or fairly applied to all developers on the team.
Second, assessment using team-based metrics may be more logical in this context. For example, a team could be measured on its output during the current sprint relative to previous sprints or on its consistent production of software that contributes to reaching company objectives.
Improving developer productivity
How can you improve developer productivity?
Whether you are a developer looking for personal productivity tips, a team leader looking to optimize collaboration and efficiency, or a company manager working to create an environment that supports your developers, we’re sharing some practical methods for improving developer productivity.
Use the best devtools
Devtools that put better systems in place improve developer productivity. But balance is non-negotiable.
Don’t put complex systems in place that make tracking a task more time-consuming than doing it. How you pick devtools is essential – and for good reason. Task management, Continuous Documentation, end-to-end testing, bug tracking, logging, monitoring, product analytics, design, and IDE devtools have leveled the playing field for developers. Robust devtools allow developers to collaborate and work efficiently – and that translates to a win on the productivity front.
Foster a collaborative culture
A collaborative culture goes a long way – with both collaborative time and focus time.
A few words about our collaborations on Slack here at Swimm: although instant messaging culture requires that we multitask, we also have come to recognize the need to turn off Slack notifications at specific times to give us more time to focus on getting the job done.
And there is always value in trying to figure out a way to institute meeting-free days. We know, not easy or maybe not even possible. Just putting it out there.
Create a culture of open communication about productivity
Companies are thinking about productivity, our team here at Swimm included. The conversations are happening on all fronts. Working remotely during Covid-19 has most definitely been a contributing factor and perhaps a win for pushing forward these dialogues on R&D teams.
What we know about developer productivity is that there are ebbs, flows, and waves. It’s not a constant by any stretch of the imagination. Having the topic out in the open helps keep the dialogue happening and keeps the conversations honest.
Use common-sense productivity
Starting with the things that make obvious sense but are too often forgotten:
- Creating a work environment conducive to productivity. Wherever you work these days, create a comfortable space dedicated to it. We’re in front of the screen all day, every day, so invest in multiple monitors, comfortable desk chairs, and standing desks. And with more Zoom meetings, you’ve got to have the very best noise-canceling headsets.
- Developing good habits. This is as much a reminder for us as it is for you. We have to get enough sleep, drink plenty of water (with our coffee), eat well, and exercise.
- Keeping our brains sharp. We do drink a lot of coffee here at Swimm. But we also hold hackathons and Swimminars, and our sprints keep us sprinting forward.
Bottom line
Using traditional metrics to measure developer productivity doesn’t work and, in our estimation, causes more harm than good.
We encourage you to continue to strategize and discuss the topic of productivity openly on your R&D teams. Ideally, these conversations should be commonplace and part of building an underlying trust about the fact that there is no magic formula for improving productivity – especially if you find yourself working hard and focused. But the conversations are still important. We hope that, out of these conversations, you improve overall developer productivity as a winning strategy on your teams.
Adding Swimm to your tool stack allows you to create documentation that is coupled to the code itself, auto-synced, and always up to date. We invite you to try Swimm’s demo and experience for yourself the benefits of Continuous Documentation: enhanced knowledge sharing, collaboration, automation, and easy onboarding – all leading, of course, to increased developer productivity.
