5 Tips On How to Measure And Maximize Developer Productivity

*header pic by Shen Comix

Developer productivity refers to the ability of developers to create high-quality software that works well and is easy to maintain in a time-effective manner. With the COVID-19 pandemic and a massive switch to home offices, businesses have been taking an increased interest in ways to increase developer productivity, including helping developers work in the flow and preventing them from burning out.

Unfortunately, instead of measuring developer productivity, many businesses have introduced micromanagement practices decreasing job performance, teamwork, innovation and increasing turnover instead. Let’s see why developer productivity is so hard to measure, which metrics are effective and why.

Table Of Contents

What’s Wrong With Measuring Developer Productivity?

• Hours worked
• Lines of code
• Bugs fixed, tasks completed or features shipped
• Computer activity

How to Measure & Maximize Developer Productivity?

• 1. Measure qualitative metrics
• 2. Keep record of quantitative metrics
• 3. Check with professional development plan
• 4. Evaluate their contribution to business goals
• 5. Trust your manager’s gut

Developer Productivity Starts Here

What’s Wrong With Measuring Developer Productivity?

To maximize profits, businesses strive to evaluate developer productivity by introducing quantitative performance metrics such as lines of code, hours, tickets, defect rate or accuracy of estimation. Let’s dig into the reasons why these metrics are not effective.

Hours worked

Number of worked hours is the most commonly used productivity metric. While it’s important for project planning, especially when combined with estimating, it still doesn’t reflect how productive your team of developers has been. Like they say, being busy is not the same as being productive and working hours is exactly about the “busy time”.

If this metric was effective, then we could get 125% of the work done if we’d work for 10 hours instead of 8 daily – that’s just maths. But in reality, our productivity drops after a certain threshold, which is proved by studies. This relation between time and output is also known in Economics as the law of diminishing marginal returns: after some optimal level of production adding an additional factor of production (number of working hours) causes a decrease in productivity and decrease in return of production.

So, if your team works a standard 40-hour workweek and you need to see how these hours are distributed across activities, tracking working hours and reviewing how they are spread across tasks is effective for workload planning and team management. But excessive attention to details and minor activities neither offers capacity for productivity boosting, nor improves team morale.

Lines of code

Some businesses think that lines of code is the direct product of the developer’s work: every line solves a problem and is by definition better than no code at all, so it must be a great developer productivity metric. But in reality it is the same trap of thinking as measuring doctor’s productivity by the number of patients they’ve had.

Why using lines of code as a productivity metric is a bad idea:

• It’s contrary to what programming is about: reducing code length and complexity.
• It doesn’t take developer experience into account. Experienced developers often use fewer lines of code than their less experienced peers for the same functionality.
• It doesn’t take into account the differences in languages. The same code could be written a dozen different ways and each taking up a different number of lines of code.
• It is an easy metric to game. Developers will be able to earn monthly salaries in a few days writing tons of unnecessary code and generate no business value.
• It sabotages the code review process making it more time-consuming.
• More lines of code ≠ more performant solution. Shorter code can work faster.
• Tons of code is hard to maintain. Unnecessary code is hard to read and maintain. Moreover, every new line of code adds to a chance of being more buggy.
• Sometimes to delete code is the most productive solution.
• Copied-and-pasted code leads to massive technical debt, poor design and higher chance of bugs.

Most importantly, measuring developer productivity with lines of code affects the performance and morale of the developers and will require time and effort to expand their code with unnecessary complexity.

Bugs fixed, tasks completed or features shipped

Productivity metrics like bugs, tasks and features are essentially as ineffective as lines of code are but are harder to game.

If developer productivity is measured by the number of bugs fixed, then they can write intentionally buggy software. Just like in this comic strip by Scott Adams:

If their goal is to ship as many features as possible, they can do it too using low-quality code piling up technical debt and making the product hardly maintainable. If developers need to finish as many tasks as possible, they will take on the easiest or the most overestimated tasks. You get the idea.

Computer activity

With the massive switch to remote work, many businesses became anxious about not being in control over their teams. They suspect that developers might slack off, fabricate worked hours in JIRA or in their timesheet software or be away during the working hours. This gave rise to a massive trend on employee monitoring software that records user activity in apps and tools, keystroke activity, emails, messengers and more. Based on this data, the software calculates productivity scores and highlights top performers.

The ratings below the charts display top productive, unproductive and effective employees based on their activity level and app usage

The biggest issue with activity tracking software is that neither of the tracked metrics are relevant to developer productivity, business performance or its customers. Would you apply disciplinary actions to a top performing developer who doesn’t use their mouse or keyboard enough? Would you promote a developer who spends a lot of time typing in Visual Studio, even if they’re difficult to work with? Makes no sense, right?

How to Measure & Maximize Developer Productivity?

1. Measure qualitative metrics

If you ask Martin Fowler, Uncle Bob Martin, Steve McConnell, Joel Spolsky or any other development luminary, neither of them could single out the most important developer productivity metric or develop a performance measurement system based on the quantitative metrics alone. Back in 2003, Martin Fowler admitted that measuring developer productivity is nearly impossible and false measures only make things worse. In 2020, Steve McConnell in his keynotes still calls developer productivity one of the most elusive objectives.

Most important factors contributing to developer productivity can not be measured. These include job satisfaction, training and development, employee engagement, goals and expectations, tools and equipment, morale and company culture. To measure these, take employee surveys regularly.

Questions to consider:

• Create a questionnaire where developers can evaluate their performance, job satisfaction, goals and expectations, tools and equipment, morale and other parameters.
• Share this list with the team lead and go through the list yourself if you are a manager to evaluate your team members.
• Compare the results to see you and your developer team are on the same page. Pay close attention to evaluations that don’t match.

2. Keep record of quantitative metrics

Tracking how developers spend their time is proven to maximize resources and improve developer performance. Another solid reason to keep a record of tasks and time spent is to document bad performance so that you can back up your decision in case termination is necessary. To make this data even more compelling, you can sort this data by activity types in your time tracking system to review developer performance across similar tasks.

Custom Fields report in actiTIME, where you can review time expenses across multiple custom types of tasks

If you notice any anomalies, review task comments and time entry notes or ask the developer to discover the reasons. Were there any unforeseen circumstances such as underestimated complexity of the task or the change of priorities? If not, dig into the task details to review the amount of completed work and discuss the reasons of the poor performance with the developer.

Questions to consider:

• How often did they miss deadlines? Why?
• How accurate are their task estimates?
• How much time does it usually take them to finish certain types of tasks? How can it be improved?
• Do they record their hours daily? If not, communicate the importance of doing so.
• How often did they work overtime? Why?
• How often did they call in sick or requested other types of absences? Were they reasonable?
• Can you identify a pattern?

3. Check with professional development plan

One of the best practices of managing developer teams is when managers build professional development plans for each of their team members.

Professional development plan documents goals, skills and competencies required for successful career development and meeting business needs. It provides managers with metrics for measuring developer performance and allows developers to get a clear picture of the skills and technologies they need to master as well as goals they need to achieve with their work. Check this plan every few months and have one-on-one meetings to review and discuss developer performance.

Questions to consider:

• How often did the developer use their skills? What competencies did they appy most often?
• How their skills affected work goals, workflow and project success?
• What difficulties did they encounter? How did those difficulties affect their work and workflow?
• What has improved over the evaluation period?
• If a developer didn’t meet personal and business goals, should you offer them additional training?
• What needs to be improved in the work of an individual developer?

4. Evaluate their contribution to business goals

Professional development plan should include not only personal career goals but also align with business goals. To evaluate developer performance in terms of business contribution, go through the following list of questions.

Questions to consider:

• What successes did the business achieve, and how did this developer contribute to them? Did they properly use their key skills?
• Have they achieved or even exceeded the desired metrics and indicators?
• Was the result of the work so outstanding that it is worth highlighting this developer?
• Has this developer played a key role in achieving the team’s goals?

5. Trust your manager’s gut

Managers work so closely with their teams that they develop good judgement through experience, learning and trust. So you might intuitively know who are the good, productive developers, who is average and who needs to shape up or ship out. Embrace that subjectivity. You should be able to tell who are superstars in your team and who needs to improve, off the top of your head.

Developer Productivity Starts Here

Productive use of time is the most important component of developer productivity and successful project delivery. Consider implementing a time tracking system that can do both – serve as a project management tool and record developer performance.

For example, actiTIME allows managers to distribute the workload across their team, specify task details and review time and money expenses across clients and projects. Get your team members to record their time across activities, change task status, add time log notes and more using online timesheet, browser extension or a mobile app. actiTIME supports 2,000+ integrations, including JIRA, GitHub, JitLab and Trello. Try actiTIME for free with a 30-day trial (no credit card required).