Smart Ways to Measure Developer Productivity
From a management perspective, especially in the technology industry, it’s extremely important to measure developers’ productivity. No wonder, because each of us works to deliver specific outcomes, and this also applies to this job role. In addition, each hour of a software developer’s work is often a big investment for the company, so it’s obvious that we try to find the best ways to measure their productivity. Peter Drucker, the father of modern management claimed that “[only] what gets measured, gets managed.”
We can all agree developer productivity has a significant impact on product or software development, however, there is a debate among developers and managers whether it can really be measured? There are many variables that should be taken into account that refer to the development process, and capturing effectively everything is actually a challenge. What’s more, some IT experts claim that measuring team or project productivity is the only right decision companies should follow.
Productivity, of course, is something you determine by looking at the input of an activity and its output. So to measure software productivity you have to measure the output of software development - the reason we can't measure productivity is that we can't measure output. (source: Martin Fowler).
So how can companies that hire programmers judge if they are working efficiently? How can you assess whether the outsourced developer for the project was a good investment? This article will help you understand how to evaluate the developer’s productivity, but it is only a starting point for your own considerations.
Difference between developer productivity and performance
There are many practices designed to increase developer productivity, the most popular is Scrum or Agile methodology but what is actually understood by the concept of productivity, and how it differs from the performance?
Productivity, in general, is the state of being able to create, particularly at a high quality and speed. Workplace productivity is the efficiency with which tasks and goals are completed at an organization. Productivity concentrates on the measure of the efficiency of a person in converting inputs into useful outputs. Productivity answers the question of how much “positive work” has been done by the developer.
If we assume that all work is “positive work” - that is, that all work represents progress toward a goal - then we are mistaken. Developers who have worked while exhausted, distracted, or sick tend to be familiar with the concept of “negative work”: work so poorly done that it must be undone or compensated for later, thus increasing rather than decreasing the amount of work remaining. (source: Stack Overflow).
Performance is often activity-based, quantitative, or qualitative, so it’s the process of achieving a task or action. Performance is the accomplishment of a given task measured by the level of success against a pre-agreed criterion: KPI, goals, objectives, etc. Performance answers the question of how well the developer did his job. The performance of software developers also includes their punctuality, willingness to collaborate, communication, and general attitude at work.
Increased performance doesn’t necessarily equate to improved productivity. Behaviorally, an employee might be meeting all of the company’s expectations. They might also be achieving all of their assigned goals. But they aren’t producing anything of real significance. This doesn’t necessarily mean the employee is at fault. However, it could mean they have inadequate goals unaligned with overall company objectives.(source: WorkTango).
What are the wrong ways to measure productivity?
The most common and also one of several false metrics are “hours worked”. It’s a tempting metric for many companies to follow because they settle accounts both with developers and IT staffing companies for the hours worked. However, time may not be related to productivity. More experienced developers can achieve more work in less time because it results from their knowledge but it doesn’t mean the rest wasn’t working productively. Moreover, a study conducted by Stanford University showed that employees who work 60 hours per week often accomplished less than those who only worked 40 hours.
Another false metric is lines of code (LOC) produced. At first, it seems objective because it can be noticed how much work has been delivered during the specified amount of time. However, there are many differences between languages and this fact alone means that they cannot be measured with this approach. Another issue is that well-designed and factored code will be shorter because it eliminates duplication. Copy and paste programming leads to high LOC counts. Counting LOC in some way encourages writing bad code over good, and the point is to write it in a way that makes it easy to manage by other team members.
Most developers and managers agree that a combination of qualitative and quantitative metrics should be taken into consideration to see if your employee is being productive. What they add is that “to measure” is actually a wrong term because it evokes a sense of objectivity, which is impossible to apply when assessing a complex work. They prefer the term “evaluation” because it determines the value of an employee according to certain company standards. It's subjective but also transparent and the evaluation can be used to have constructive discussions that lead to improvement.
How to measure a programmer’s productivity?
There are many factors that can be taken into account when evaluating a developer's productivity. Productivity doesn’t necessarily mean speed of development, but rather a robustness of delivered code or feature. As an example, software or product evolves and over time it’s often necessary to update and grow its features. Productivity means the developer predicted that and made a code flexible enough to avoid rewriting them entirely in the future.
What are the 4 best indicators worth looking at during the evaluation?
1. Closed Tickets
Tickets allow Project Managers to monitor work to be done by an individual developer. Counting the number of tickets a developer closes over a specific period is a way to see what actual work is getting closed off and which developer is involved in more important tasks. However, tasks in tickets should be assigned in terms of business priority and written properly. Not all tickets are equal, which is why they should be scored by effort. It also makes it possible to see what tasks the developer chooses to deliver (and if the person avoids the hard ones). Common tools used to measure closed tickets are GitHub, GitLab, Jira, or Trello.
2. Completed Code Reviews
Measuring completed code reviews means counting how many code reviews are submitted or reviewed by someone on the team and can help you to evaluate developer productivity - if code reviews are submitted then probably tickets are closed as well. Code Reviews should be conducted after automated tests have been completed successfully, but before the code merges to the repository’s mainline branch. Those software developers who are good committers or reviewers are also the ones who are motivated to work efficiently. Recognition of coding expertise through peers gives them a sense of satisfaction.
3. Deploys
A deployment is a unit of work that has made it from the development stage to a live web server. It’s a useful measurement of productivity because of the visibility of changes in a project. Once something has been deployed, it’s being shared with users. They often quickly provide feedback on the value of it. Developers who care about quality - those with whom you want to work - won’t release the code that wasn’t written correctly just to achieve greater perceived productivity. Another thing worth mentioning is to work out the deployment workflow - developers should know who and when can perform a production deployment because if it takes “forever” it can demotivate.
4. Feedback from the team
What we also use, at Blue House, to evaluate the productivity of developers who are a part of our IT Community is feedback from other team members. After the developer finishes working on a project for our client, we reach out to other IT experts who were on the team and ask how they felt while working with a specific person. Were they responding quickly during agreed time slots? Were they well-prepared for the meetings? What do they think about the specific developer’s skills and engagement? This is the best way to receive information that often can’t be reflected in numbers but which we believe are as important.
Summing up
What matters in measuring developer productivity is to use consistent measurements for all team members both in-house and outsourced. Besides numbers, think also if features added by a specific IT expert were delivered on time and within the expected tolerance for quality? Is each person on the team communicating effectively with Project Managers and stakeholders? Together they tell a story, especially when you track them over time.
Imagine software engineering as a pipeline. Ideas come in, and what goes out is (hopefully) quality software to solve a problem or create opportunities for the business. Framed this way, what business leaders want to know about engineering is: how much do we get through the pipeline, how quickly do we do it, how good is what comes out? (source: GitClear).
If you don’t want to waste time and money on developers who aren’t productive, reach out to an IT staffing company that knows well their developers - not only their skills. We built Blue House based on the passion for people and technology and the feedback culture supports our vision: IT experts and entrepreneurs cooperate to build great software together.
You may also want to read:
Don't miss out on any content that will help you to achieve desired outcomes and smoothly run IT projects.
