Measuring developer productivity in less time — and how to get better results
Posted by Bill Harding at GitClear
As a development manager or CTO, can you answer these questions?
- How much productive work did my developers accomplish last week?
- Is the volume of productive code my developers produce rising, falling, or staying flat?
- Which developers are making the most consistent, impactful contributions?
If you aren’t 100% sure about the answers, you’re not alone. Development managers and CTOs often find they have to rely on flawed information to assess and manage developer productivity. Sure, you’d like to have accurate data on your team’s performance, but who’s got the time to go through all those lines of code?
You do.
With the right tool you can reduce, or eliminate, many of your biggest time sinks — and get a better picture of your team’s output. Here are four areas where automation can earn back chunks of your time.
The four biggest time-wasters for CTOs and development managers
Building your team
Skilled developers are less common than bug-free code. When you’re lucky enough to hire one, you need to get them up to speed as fast as possible. Pairing your new hire with a mentor is a great way to do that — someone the new hire can look up to as an example.
But how do you identify a consistent producer to be the mentor — by counting the lines of code they produce? By manually evaluating commits? By gut feeling? The cost of picking the wrong mentor could be high.
Without an accurate measure of productivity, you can’t really know who might set the best example. Your new hire might pick up habits that end up destroying their productivity, not enhancing it. Correcting that is expensive. And if they don’t work out, you’ll have wasted a lot of money and time while recruiting, interviewing, and on-boarding them.
Reviewing code
Development managers spend an inordinate amount of time reviewing code that doesn’t actually need to be reviewed. The numbers can be shocking. For example, managers often review code that’s removed a short time later — that single scenario (“churned” code) represents 35% of all committed lines in some repos. Plus, a lot of code we think is new, isn’t — it’s existing code that simply moved from one place to another. The cost of not being able to recognize those lines? An additional 15% of your valuable time.
The traditional code review process is fraught with inefficiencies that impose a subtle time-tax throughout your day, leaving you with less time to focus on the people management or code-writing aspects of your role.
Doing employee reviews
The average development manager devotes four to eight hours to an employee review. Typically, managers look at the number of closed tickets, maybe some commit stats on Github, and then summon their memory to fill in the rest.
It’s hard to recall something that happened three months ago, let alone to compare it on equal footing against a feature implemented 10 months ago. Developer productivity can fluctuate based on the type of tasks they’re assigned, so you ideally want to identify and discuss that as well. By focusing on just the last few months, you may end up penalizing, or promoting, the wrong person.
The cumulative effect of a bad decision? Overlooking the real contributors. Asking the rest of the team to compensate for an underperforming teammate. Spending hours interviewing candidates to replace the superstars on your team who didn’t get the recognition they deserved.
Attending non-productive standup meetings
Sit down, brace yourself, and tally up the time you spend in standups and other status meetings. How much of it was productive? Don’t get me wrong, standups are essential if — and it’s a big if — they are a forum for making decisions that move the project forward.
The trouble is, without reliable, detailed metrics, standup meetings often end up being a fact-finding mission about who’s been working on what, or a debate about how much progress was made. Those basic facts should be possessed by everyone before the meeting. Status meetings devote too much time to gathering information, instead of identifying and removing roadblocks.
Measuring productivity with precision
From the weight of a feather to the speed of light, everything in our universe can be measured. With the right tools we can measure time, power and speed with an astonishing degree of granularity. When it comes to things like suspension bridges or open-heart surgery, we don’t settle for guesstimates. Why then, does the field of software development accept such a flawed system of measurement?
More code doesn’t necessarily mean more value
The speed at which a developer produces lines of code can be an excellent indicator — of keyboarding skills. When it comes to measuring the impact of their work, not so much.
First of all, it’s easier to write code in the early stages of a project than it is later on. Some languages require more lines of code than others. And it’s easy to source code from libraries or automatically generate it. Third-party and library code accounts for up to 25% of the code checked into repos we analyze.
It’s also important to take churn into account. Reviewing the instances where lines of code were added and then quickly deleted masks the true of value of the code delivered.
Commit counts are not a reliable metric unto themselves
Developers have unique styles of working. Some take a long time to deliver a commit, but their code requires less rework. Others finish quickly, but need to make multiple revisions, perhaps after receiving some coaching from a lead developer. An overly optimistic commit can count against a developer if major revisions are needed. That provides developers with an incentive to be overly cautious when making a commit.
Sometimes commits that are insignificant alone can provide more value when they’re combined. Analyzing two or more commits as a single set of changes is a more precise method of measuring contribution.
Accurate measurement requires precision
Improving accuracy requires tools specifically optimized for assessing developer impact. GitClear uses several different data points to get a complete picture of the value of a commit.
GitClear combines all these data points to produce a new metric we call Line Impact. By providing a true measure of output, GitClear saves managers time.
It starts with a reimagined diff viewer that makes it easy to see where the real work happened in a commit. Updated code is highlighted, making it easy to see where the changes are. Moved code is identified and minimized. And the leaderboard feature helps identify which developers are the biggest contributors, so you can focus on making your top developers even more successful.
Spend five minutes to save dozens of hours
Gitclear can be setup in less time than it takes to conduct a typical department meeting. Just import your code repository from Github, and five minutes later you’ll have the insights you need to save time and gain a better understanding of your teams’ performance. You’ll shave precious minutes off the time it takes to review code and build an efficient team. It doesn’t take long for those minutes add up to hours.
Ready to learn how GitClear provides a true measure of developer performance, in less time?
Originally published at www.gitclear.com.
