“What gets measured, gets managed”, once said by Peter Drucker. In today’s competitive business environment, project managers, stakeholders, and executives want to quantify the output as much as possible.
In software development, just like any other field, many people consider productivity in terms of inputs and outputs. For an average salary of $107,510 per year, a full-time developer works 40 hours/week in the US. Salary and hours are easy and visible quantifiable inputs. The developer then puts bug fixes together repeatedly, produces deployments, documentation, and software features. These are outputs.
There is another school of thought that has a different opinion! They believe that there should not be any form of quantitative metric for measuring developer performance.
“For software developers, measuring productivity using quantitative ways of any form may lead to lesser productivity overall. It also hampers the motivation, and will eventually drive good people out.” — vartec
No doubt, the above views hold some merit, but there has to be some way to measure the quality of individual developers. Measuring developer productivity is an inexact science, but how do you know where to focus and improve if you don’t measure? A CEO or a CTO needs to identify and implement clear methods of measurement, and they need to be communicated to the development team.
Below are some ways to consider how not to and how exactly to measure a developer’s productivity.
How NOT to Measure Developer Productivity
1. Lines of Code
Do we even have to discuss this one?
The solution to complex problems may sometimes be to delete lines of code. Similarly, a more efficient developer may be able to craft a solution in a few lines of code, as opposed to hundreds or thousands.
Some team leaders and project managers may consider that the more lines of code a developer can write in a given amount of time, the more productive he or she is — which eventually becomes a terrible idea.
2. Hours worked
This one should be obvious, too. Time worked as a measure of productivity is a lose-lose scenario. The most high-performing, efficient, and productive developers achieve more work and solve more difficult problems in less time.
A study from Stanford University showed that when employees made to work 60 hours per week accomplished less — in aggregate — than employees who only worked 40 hours. The findings showed that overworked people may even begin to clock negative productivity. This would likely lead to an increase in errors or oversights that developers then need to correct later.
3. Bugs fixed
It’s not the smartest way to measure a developer’s productivity.
I think Dilbert can sum up the problem, just in case it isn’t clear at first glance:
Needless to say, measuring productivity in terms of bugs fixed, or features shipped is equally pointless.
4. Tasks completed
We know that not every task is equal in terms of work required or complexity. Simply measuring productivity by tasks completed is not a smart way to understand productivity. We need to have a better system.
Smart and Better Ways to Measure Developer Productivity
The unfortunate truth is that not all metrics have a clear north and the same applies to measuring developer productivity. But, there’s always a way to develop the right strategy for your specific team–or specific team members. Read through these ways and find the ones that best fit your situation.
1. Documentation Created
Often overlooked but one of the most important parts of development is documentation. So keeping documentation in mind, it may be useful to set up a developer productivity goal. It can take many types, from READ ME text to comments and more complex manuals. But, regardless of the type, it can have a lasting impact, possibly even after the developer leaves the project.
2. Closed Tickets
Tickets allow many software projects to monitor work to be done for individual developers. By counting the number of tickets closed and looking at the type of work during a certain time, you can see which developer is involved in more important tasks. If the tasks are assigned in terms of business priority and written properly, then measuring closed tickets may be a better metric to measure developer productivity. There are also many different ways to measure closed tickets, and many tools, such as Jira or GitHub, are available.
3. Completed Code Reviews
Code reviews are an important part of any high-functioning software development team and can also help you to measure developer productivity. Measuring completed code reviews shows how much buy-in code review has with your team. At the same time, if your developers are submitting code reviews, then, presumably, tickets are being closed and your project is moving forward. Therefore, it becomes the complementary measurement for some of the previously mentioned metrics as well to measure developer productivity.
With deploys being a useful measurement of productivity, you can measure the changes in a project that are being shared with your users.
Many tools are available today to measure deployments in an easy, automated way that also allows you to see what work went into the deployment. This ensures that the code quality is at the highest possible level, and encourages your team to release code quickly and often.
So, when a developer works to maintain a high level of code, measuring deployments can be a creative and insightful way to measure their productivity.
There are many available metrics when it comes to developer productivity. Traditional methods of measurement like lines of code written and hours worked often do not give the best view of actual developer productivity. Other metrics like closed tickets, completed code reviews, and even conversations with other employees can give you a much better insight into the developer’s productivity. It’s on you to decide which metrics are best for your team. And one way to do this is to decide what is to work on the priority when it comes to work that needs to be accomplished.
We are providing practical training (Labor Laws, Payroll, Salary Structure, PF-ESI Challan) and Labor Law, Payroll Consultant Service & more:
- HR-Generalist-Practical-Training: https://oneclik.in/hr-generalist-practical-training/ (PF, ESI, Bonus, Payroll & more)
- Labour Code | Labour Bill (Labour-Law-Practical-Training): https://oneclik.in/labour-law-practical-training/ (Factory, Contact Labor, Maternity Act & more)
- PF – ESI Consultant Service: https://oneclik.in/pf-esi-consultant-service/
- Labor Law, Compliance & HR – Payroll Management
- Advance Excel Practical Training
Get Latest HR, IR, Labor Law Updates, Case Studies & Regular Updates: (Join us on Social Media)