In today’s fast-paced software development lifecycle, creating an efficient team is crucial. Traditional metrics like lines of code or number of pull requests present an incomplete picture and can incentivize wrong behaviors.
These metrics can help identify areas for improvement, allowing teams to implement targeted solutions and ultimately boost overall productivity.
Let’s dive in.
Clear thinking is fundamental to achieving efficient results. Nisída Ágios Nikólaos, Island in Epirus, Greece gives the needed rest and enhances brain function.
Rethinking the Common Metrics
Number of pull requests
I know it is easy to visit the contributor analytics and see the number of pull requests and commits per developer. For sure it is a number, it is measurable, but the essence of it is flawed. The developer may target shorter, probably lower-value commits and pull requests to increase the number.
This metric may incentivize verbose or redundant code rather than efficient solutions.
Lines of Code
Similar to the number of pull requests, if this metric is communicated to be important, it will lead the developers to “engineer“ their style of coding to deliver quantity over quality. The sheer volume is not what we want to do.
Solid Productivity Metrics
What if we forget the commits and lines of code and try to measure what matters for developer efficiency?
Here are seven ideas:
1. Gauging Developer Sentiment
It may sound a bit funny and maybe unprofessional but it makes sense to ask each developer one by one but also all together if they feel productive. It is a good metric because it is not exactly measurable with numbers.
The developer will tell you I feel “totally unproductive“, or “not so productive“. People tend to exaggerate sometimes but this is what a manager has to do, diagnose the situation, ask around, and take notes.
Another approach would be to send out a survey and analyze the results.
The second step to make it measurable would be to map each opinion to a number corresponding from 0-10. For example, “totally unproductive“ would be 0 or 1, “not so productive“ would be 3, and so on. Then you can calculate an average. However, while self-reported productivity can offer valuable insights, solely relying on a 0-10 scale might be subjective and prone to bias. That’s why we are not only talking numbers here.
2. Delivery Time
Simply put, how long does it take to deliver a feature or bug?
From the moment a developer gets assigned a work item until this is delivered to production. This metric includes the following:
Development
Writing unit tests
Manual end-to-end testing by the developer
QA Testing on pre-production environments
Building and deployment to various environments
Delivery time shows how much time a business requirement needs to be delivered to the real users of the system, something that offers consistent value to the system and the company.
To accelerate the Delivery Time, we need good DevOps practices. That is Continuous Integration/ Continuous Deployment. We need pipelines that build and deploy. Tools like Azure Devops, Github Actions, and Gitlab pipelines. We also need the work items to be analysed before a developer starts working on them. We also need automated end-to-end testing.
Of course, worth noting is that factors like project complexity and unforeseen issues can influence the delivery time. Context is necessary when evaluating this metric.
3. Frequent and fast deployments
In the past, companies took years to ship a product. Famously Microsoft took 5 years to ship the next Windows platform from Windows XP (2001) to Windows Vista (2006). Even big companies slowly embraced a more agile approach trying to ship more frequently.
To deliver software fast we need great DevOps practices. As explained in 2. Delivery Time, we need CI/CD pipelines, build and deploy to be executed fast.
Deployment frequency is influenced by the growth of the engineering team. More developers usually means more code written, that is slower deployments. This is why the pipelines should be up and running the tests.
Frequent and fast deployments allow fast shipping of features and potential bug fixes. This makes customers happy. The roadmap can be fulfilled faster and the product can evolve much faster. This also allows the executive team to better plan the roadmap and have a strategy since they can rely on a solid product shipping foundation.
4. Incident Resolution
How long does it take to bring the system back to normal after an incident?
An incident happens. Hopefully, the monitoring system detects it and triggers an alert sent to the user support team and/or the system administrator. Even worse, a user calls or opens a ticket complaining that nothing works, and the system is down.
How long does it take to restore the service?
If we have a policy of always creating a ticket for this, we can track the time the ticket is marked as resolved.
Handling serious incidents can easily break the trust the customers have in the company and things can escalate fast. A short time to restore service allows organizations to introduce innovative features with confidence, thereby driving competitive advantages and achieving business goals.
I remember a time when we had recently developed a feature introducing a bad SQL query doing 4 joins which, with the production data exploded the server. We did not have good monitoring at the time and a Senior Manager from a customer called the user support who were out on a break. Well, this did not end up so well…
We set up a better monitoring system detecting anomalies using the logs and also pinging the components for health checks. We also made sure there was at least one user support person answering the phone!
5. Rollback Rate
Let’s say we have implemented an amazing feature that will most probably change the world. It passed all the tests and looks super. Production deployment happens and somehow, either because of the database data or the traffic, we realize that it is not performant enough and has to be rollbacked. We may need to cancel the release.
How fast can this happen? How fast can we roll back the whole system from release 3.3 to 3.2 for example? How long will the downtime be? Minutes, hours, or a couple of days maybe? Again, good DevOps practices with CI/CD automated pipelines can greatly improve and fasten this process, health checks help as well.
The rollback rate contributes to a stable and reliable software delivery process.
6. Emphasizing Code Quality
I am a believer in code quality and many developers agree with that. Code quality, contributes to easier understanding, maintainability, reduces bugs, improves collaboration and lowers the long-term effort for modifications.
Automated metrics using tools like SonarQube to measure unit test coverage, code complexity, and identify potential issues through static code analysis are useful to measure code quality.
Manual code reviews by senior developers ensures code adheres to standards and helps collaboration in the team.
7. Addressing Technical Debt
Technical debt is built when we take shortcuts and rush code into delivery without taking the time to design it well. Without the right amount of time, best practices are not respected and we may make mistakes that we have to pay later. This causes frustration to the developers who are asked to develop on top of something unsustainable. They complain but product people prioritize things that have higher business value. We can see it as a financial debt. We have to pay it off to go to a healthy financial situation before we can jump on an investment.
Managing technical debt can improve long-term developer productivity by reducing the time spent fixing issues caused by past code shortcuts.
An interesting approach is to build a backlog of technical debt with estimated tasks. This way, the product people and managers can plan more easily and see what they may want to exchange for lowering the technical debt. This way it can also be measurable.
Conclusion
All the abovementioned metrics can be measured and followed for their progress. They are interconnected. They can serve as a part of the company strategy to improve delivery and customer satisfaction. They can greatly improve developer productivity and overall motivation.
I want to emphasize the fact that even though metrics are useful, it is very important to set realistic goals and establish a culture of continuous improvement to effectively utilize these metrics.
I encourage you to assess these metrics in your teams and share any additional insights or best practices.
Do you have real work-life example of measuring your team’s productivity? I would like to know more.
Feel free to add a comment or contact me directly for related ideas!
Enjoy!