Developer productivity is something that software development companies chase day in and day out.
And it’s not surprising. A productive developer is someone whose work is valuable and who keeps producing results. What business wouldn’t want that?
However, developer productivity is a layered topic. What does it even mean for a developer to be productive? Why is it important? How to measure it, and can we improve it?
In this article, we’ll examine those questions and offer some insights, so stay tuned.
Table of Contents
What is developer productivity?
It seems like developer productivity is a go-to term in today’s tech industry when someone needs a buzzword to describe why a software development company is successful.
But is it more than just a fashionable phrase?
Let’s start with defining productivity in the workplace. Here’s an interesting definition from Investopedia:
“Productivity in the workplace refers simply to how much “work” is done over a specific period of time.”
Why is it interesting? Notice the quotation marks around the word work—it turns out that that’s very relevant for defining developer productivity.
Below is another definition of developer productivity from Ashley Kim, Solutions Architect at LaunchDarkly.
As you can see, in addition to the timeframe, she also mentions metrics as an essential element.
Metrics are crucial for developer productivity, as we’ll explore more in detail in later chapters. However, it’s important to touch on them now, too.
For example, take a look at how many hours a week developers worked in 2020 globally. According to Statista, most work 40 to 44 hours a week.
Does that mean that those who work more hours are more productive?
As we’ll see in the later sections, not necessarily—the number of hours doesn’t always correlate with developers’ output.
So, if that’s not what developer productivity is, can it be something like this example below?
This tweet showing a large number of code contributions attracted a lot of attention.
In nearly a thousand comments, many pointed out that this amount of contributions doesn’t necessarily mean that a developer is highly productive.
Furthermore, Nicole Forsgren points out that the notion that developers’ productivity is about their activity is a myth.
Here’s how she explains why that’s the case.
Therefore, determining what developer productivity is can be challenging because of the many factors that contribute to it.
Forsgren and her fellow researchers recognized that and created SPACE, one of the popular frameworks for that purpose.
Get unreal data to fix real issues in your app & web.
According to them, it’s a combination of many elements that fall under the following categories:
- S: Satisfaction and well-being
- P: Performance
- A: Activity
- C: Communication and collaboration
- E: Efficiency and flow
You can learn more about it in the video below.
The point is that developer productivity can’t be precisely measured by a single metric, whatever that metric may be.
It’s a complex combination of several factors, occurrences, and variables, many of which result from that same complex nature of software developers’ work.
At Xpirit, they know that, so they use the SPACE framework for assessing their developers’ results.
As their CTO Marcel de Vries explains, they learned what developer productivity is by using the SPACE framework.
“The SPACE framework gives us an even better understanding of what factors increase or decrease productivity in your business.”
With that understanding, they can identify what is beneficial for productivity and have a targeted approach to improvement.
That’s also why developer productivity matters for a company, as well as developers themselves—let’s explore that in the next section.
Why does developer productivity matter?
If developer productivity is such a complex concept with many moving parts, should we even bother measuring it and trying to improve it?
According to data, yes—if you want your developers to be happy at work.
A survey from StackOverflow indicates that a strong sense of productivity at work makes developers happier, and a lack of it makes them unhappy.
Even if you don’t particularly care about the individual happiness of your software developers on a personal level, the fact is it’s good for the business.
Shawn Achor analyzed 200 studies on happiness and found that happy employees are more creative, accurate, and have better analytical and problem-solving abilities.
Also, a study from David C. Wyld suggests that happier employees don’t leave their employers as much as unhappy ones.
“The study found that more satisfied employees and more “embedded” workers were less likely to leave.”
Therefore, it seems like developer productivity matters, both for the developers and their employers.
However, besides those mentioned reasons, it also matters from a purely business perspective.
Software development isn’t that different from any other type of business when it comes to results—if you want to improve and reach your goals, you should increase productivity, and to increase it, you should find a way to measure it.
Martin Fowler sees the appeal and importance of developer productivity, regardless of his issues with common approaches to it.
Even if experts don’t agree on what metrics to assess it with, many of them agree that developer productivity should be measured in a team context.
For instance, Netflix goes above and beyond to ensure that their developers can be as productive as possible.
They have Productivity Engineers who keep the work of software engineers streamlined and remove any obstacles to efficiency out of their way.
Below, you can see how Kathryn Koehler, their Productivity Engineering Director, describes that.
In short, they believe that developer productivity matters because it means that the developers do their best work.
Besides that, they focus on measuring team productivity and go even further—they consider the project a team is working on, their experience, customer base, and many other factors.
You can learn more about their approach in the video below.
In other words, the productivity of a software development team matters more than the productivity of an individual developer.
But how to measure developer productivity if it’s that important? As you may guess by now, it is a complex matter.
Let’s dive into it in the next section.
Can you measure developer productivity?
As we touched on in the previous sections, measuring developer productivity can be complex—to the point that there are discussions about whether we can do it at all.
Some experts, like Martin Fowler, argue that we can’t, or more precisely, that the metrics we use to do it are flawed and paint only a distorted picture.
However, according to data from Pluralsight, most developers think that measuring productivity is possible. In fact, 89.2% of them believe that there are good metrics for it.
In light of those differences in thinking about developer productivity, it isn’t surprising that different companies have different strategies for measuring it.
For example, Google uses a system called GSM, which stands for Goals/Signals/Metrics.
Here’s how Rodden et al. define it in their paper.
“We developed a simple process that steps teams through articulating the goals of a product or feature, then identifying signals that indicate success, and finally building specific metrics to track on a dashboard.”
In short, a goal is the desired end result, a signal is how you might know you achieved it, and a metric is a proxy for a signal—something that can be measured.
You can read more details about GSM and the metrics Google uses in this article, but one thing’s for certain—the metrics aren’t traditional ones because, in the software development context, those aren’t that useful.
For instance, take a look at this piece of code below.
If you measured developer productivity by the number of lines they write, that example would constitute a better piece of code than the one below.
Of course, most developers with any experience would say that the second one is more clear and simply better written.
That’s why lines of code are not a useful metric. More lines don’t necessarily mean that a developer is more productive.
Jez Humble, Site Reliability Engineer at Google Cloud, pointed out that it’s actually often the opposite—less is more.
The situation is similar with other conventional metrics, like the number of hours worked. There’s no guarantee that developers are more productive if they sit more hours in front of their screens.
What about code commits? On average, developers at Microsoft have 8,421 code pushes a day. However, that doesn’t tell us anything about the value of that code.
While there’s no clear consensus about the best metrics, here are some that are commonly considered as such:
- Cycle time: how much time do project stages take
- Lead time: how much time is between the beginning of the project and the delivery
- Velocity: the amount of work that your team can accomplish in a given time
- Customer satisfaction score: how satisfied the is the customer with the product/service
You can find more of them in this article, but as you can see, good metrics consider the nature of developers’ work. They don’t treat it like any other 9-to-5 job.
How to improve the productivity of your development team?
Until now, we examined what developer productivity is, why it matters, and whether we can even measure it.
But how to improve it? Luckily, there are a few simple but effective ways to raise your developers’ productivity worth considering.
Let’s take a look.
Decrease the number of distractions for your devs
Your developers should have enough distraction-free time to focus and do their work. If you manage to provide them with that, their productivity will undoubtedly improve.
That’s because distractions can greatly affect the work process.
According to data presented by Gloria Mark, it takes, on average, nearly 25 minutes to get back to work after someone interrupts you.
One of the things you can do to minimize distractions for your developers is to do your best to eliminate any work that isn’t strictly development-related.
That means, for example, reducing the number of unnecessary staff meetings that can cause them to lose their flow.
You can also provide them with a distraction-free environment. For instance, below, you can see how many types of distractions there are various office layouts.
That means that, for example, if you have an open office plan, your developers could lack sound and visual privacy, and be distracted by the noise of everyone around them.
A solution for that might be something like Framery’s soundproof pods that provide privacy.
On the other hand, if your developers have good working conditions and the distractions come from their computers, there are solutions for that too.
Cold Turkey is a software that blocks websites, games, and apps to boost productivity and make focusing on work easier.
You should work with your developers to decrease the number of distractions they face daily, and produce a much-welcomed productivity increase.
Communicate regularly with your team
Regular communication with your developers is an important factor in increasing their productivity.
Healthy communication can help your team to discuss their needs, issues, and ideas they might have.
They should have an opportunity to do so—otherwise, the frustration and unhappiness can build up, which isn’t good for productivity.
You can provide them with those opportunities by regularly having 1-on-1 meetings with developers.
For example, that’s what Kim Scott from Radical Candor practices.
During her 1-on-1 meetings with the team members, communication goes both ways. The employees get the feedback, but the manager also asks questions that help them to open up:
- What’s on your mind this week?
- How happy were you this past week?
- How productive were you this past week?
- What feedback do you have for me?
That communication style can contribute to better relationships, which in turn produce happier and more productive developers.
Set reasonable deadlines
If you want to increase your developers’ productivity, you should consider how you set deadlines for the tasks and projects they’re working on.
Reasonable deadlines can motivate your developers and give them a sense of accomplishment.
On the other hand, being unrealistic with deadlines can cause them stress and frustration—and you can be confident that that won’t lead to better productivity.
One of the good ways to make most deadlines more reasonable is to let your developers focus on one thing at a time.
According to research, only 2,5% of people are good at multitasking. For the rest, tackling one thing at a time is a more productive strategy.
Once you set reasonable deadlines, you can provide your team with a tool like Timely for more efficient time tracking.
That way, your developers can stay on top of every deadline, and you can also get the data that can help you adjust your deadlines in the future.
Help devs automate repetitive tasks
Software developers usually have enough on their plate even without tedious and repetitive tasks that waste valuable time.
Tasks like generating API documentation, gathering data, or generating reports can be automated and save time and effort for developers.
The same is true of dealing with bugs. According to Vlad Giverts, co-founder of Warmspace, that shouldn’t eat up much time.
“If it’s more than 20% of your engineering time, you might have a quality/architecture problem that is a drain on your productivity.”
Our own solution, Shake, can significantly reduce the time your developers spend on fixing bugs.
With Shake, bug reporting is automated, so developers get detailed reports from users almost instantly.
Shake can be easily embedded into any app. With it, a user just shakes their phone when they notice a bug, and Shake automatically creates a comprehensive report for developers.
When every relevant piece of information they need for fixing a bug is at their disposal, developers can save lots of time.
There’s no needless back-and-forth with the user or further investigation of the bug.
It provides developers with more time to spend on other tasks and, therefore, be more productive.
Conclusion
To successfully tackle developer productivity, you need to know what you’re getting into.
As we showed in this article, to have productive developers, it isn’t enough just to sit them at their desks and stick a motivational poster on the wall.
You should know what developer productivity is, why it’s important, how to measure it and what to do to improve it.
With those basics, you can start building a productive software development team that can achieve great results.