Developer Performance Metrics: What You Need to Know
Quantifying developer or engineering productivity has always been complex and often misleading. Software engineering is a creative, collaborative, and high-skill endeavour. Measuring the performance of such a multifaceted role is fraught with missteps, myths, and mistakes.
Why Measuring Developer Productivity Matters
You might ask, does it even matter to measure the engineers' productivity?
Imagine every day you go to a grocery store to buy a pack of nuts. Without giving much thought you purchase whatever is nearest to the counter. If you are not mindful, all that will be left in the mid month is literally peanuts.
Puns aside, if we are measuring something for the right reasons, we can improve or assess the current situation accurately. If you are not completely sold on the idea of measuring performance. Here are three more reasons why it makes sense to measure performance:
When teams perform well in software delivery, more likely the organizations will reach or exceed their goals.
As a developer, I am always on lookup for ways to improve my productivity, eliminate the distractions, decrease the frustration and increase impact I create.
As an engineering manager or team lead, I wanted to find if the developers are effectively delivering the best code possible with as few defects as possible.
Measuring Productivity in Technology Teams
Now that I have your attention, can measuring developer productivity be straightforward? When a salesperson's productivity can be measured by the number of sales or amount of sales closed in a month, or an Investment manager's performance can be measured through returns generated, why cannot a software engineer's productivity be measured so simply?
After all the software engineer's role is to write code and deploy code right?
Let me explain this with an example, imagine there are two developers in Awesome Inc., John who writes 250 lines of code every day and Angel who writes 105 lines of code. Who is more productive? To complicate things, whenever John deploys something to end users, the system almost always crashes. Now who will you vote for? To further complicate, Angel's team on the other hand pushes changes to production once every week whereas John's team pushes every 2 weeks. Which team has better performance?
This has been the frustration of many leaders, these simple metrics often paint an inaccurate picture. When a company chooses to award developers on these incomplete metrics, guess who is getting the bonuses or rewards. To complicate things, several factors influence the impact of the work that these engineers do, the tools available, processes, and the work environment.
Unpacking DORA Metrics: The Key to DevOps Success
The research program conducted by industry trail blazers Dr. Nicole Forsgren, Gene Kim, and Jez Humble and later acquired by Google, has become the industry standard in measuring the performance of software teams. The DORA metrics are an output of the research across 10000 companies through 2014.
Dora has identified four key metrics that provide an effective way of measuring outcomes of software delivery process. These four key metrics measure the stability of the delivery and the velocity with which the delivery is done. Development Frequency and Lead Time to Changes measure the velocity with which the software delivery process is executed and Mean-Time-To-Recovery measures how quickly the software can bounce back from an application crash or error.
Deployment Frequency: How Often Should You Deploy? This metric measures how often application changes are deployed to production system. More often the changes are comensurate the agility and responsive delivery processes.
Lead Time for Changes: Essentially answering the question, "Can you speed Up Your Development Cycle"? by tracking the average time it takes for a change or commit to move from development to production. The lesser lead time, more efficient is the delivery process
Mean Time to Recovery (MTTR): Answers the question, how quick can the system Bounce Back? This is the time taken to recover from a failed deployment. The lesser time it takes for the recovery, the better the delivery process is.
Change Failure Rate: Measures the how frequently does the deployment causes failures in the production requiring rollbacks or hotfixes. This metrics answers the question," How risky is software deployment?". For a stable system, the failure rate should be aimed to be less.
What are the next steps?
While these metrics measure the overall delivery efficiency and stability these are not the single set of metrics that can give the whole picture about the team and its performance. In fact, Microsoft and Github has jointly researched on this and create a second set of metrics called SPACE metrics, measuring the well being of the teams and much more.
Want to dive deeper? Here are some resources to get you started:
