Improving Developer Efficiency
Developer efficiency is a specific, yet evolving thing to discuss. This topic has been brought up ever so often over the years and the approach is constantly changing, following the latest best practices. My previous experience in introducing agile method to developers was pretty successful. They have the opportunity to quickly gain clarity on what to develop, stay focus, and receive the opportunity to evaluate and iterate the software. Reducing the amount of thing to guess and context to switch is definitely a huge boost in improving the efficiency.
But what is efficiency in the context of a developer’s workflow? Taking into account the famous words of Peter Drucker, “Efficiency is doing things right; effectiveness is doing the right things,” there’s a lot to learn here. Effectiveness will definitely have a strong correlation with the end product of a developer’s activity, i.e. ultimately, what does the written code ended up impacting the product and its perceived value from the user’s perspective. Product management definitely plays a huge role here, to guide the developer into building the right software.
Now, efficiency is more about the actual process of building the product, or in the context of a developer’s life, the actual activity of writing code. Sure, effectiveness plays a factor here too, having a clear guide on what to code as mentioned in the opening paragraph, will improve the efficiency itself. But, is that it? Is there any factor to consider?
Now, taking a hat of a developer for a second, I will guide you on what a developer usually does from a higher level perspective. In order for me to write a code, I need have enough knowledge on how a system behaves or expected to behave. This may not involve any form of writing code. I can have a discussion, read or write a document, brainstorm, etc. After gaining enough information, I can start to write the actual code. In this more specific activity, I think in how each line of codes that I write will interact with each other to perform specific task(s). I can validate that the code has reached its intended result through series of test and iteration. Once it’s done, I need to integrate it with the bigger, incumbent set of codes, looking at the code from a higher level, and again test and iterate to validate. In the age of microservices, this may also involve some knowledge on how each neighbouring services are talking to each others so if there’s an issue, I can isolate whether it’s happening on a logic level or on traffic level. Once it’s valid, I can ship it (in varying level of complexity, might be a push to a repo that automates a CI/CD pipeline, or even a direct upload to server).
That brief explanation, sheds light on how a developer is expected to perform his/her activity. One thing to note is that while writing code is the one thing expected to be done, and that’s why a developer is hired in the first place, it’s not the only thing that he/she does. Unfortunately, only when a developer writes code, then a true value of the role will be realized. Sure, there’s a value in reaching a conclusion after debugging a code bug or troubleshooting a connectivity issue, but only after the fix is in place (obviously through coding) then a developer’s activity can be deemed valuable.
In this article beautifully written by Beyang Liu form Sourcegraph, there’s a theory about a developer’s inner feedback loop, one that involves actual feedback loop while writing code, as I described above. And I can’t give enough credit for that article as it clearly communicates the same thing that I thought. When we talk about efficiency, it’s only when a developer is empowered with enough information to quickly back writing code that we can say the working system is efficient. If a developer need to take 3 days to find a root cause of a trivial bug, that involves 1 day of finding the correct documentation since the person who originally wrote the code has left the company 3 months ago, and took him additional 3 days to validate that the fix is correct, then it’s going to be hard to argue that the workflow is efficient.
When we talk about efficiency, it’s only when a developer is empowered with enough information to quickly back writing code that we can say the working system is efficient.
So how can we measure effficiency? After all, we can’t improve what we don’t measure. Yes, there are famous metrics such as DORA and SPACE that experts in this field has proposed and accepted by the industry. They’re a good indicator on the current state of the workflow. But I’d argue that those are lagging indicators. If we’re to improve, which means promoting changes, we need leading indicators, something that highlight activities that we predict can lead to desired changes. (read more about lagging vs leading indicator here).
This article by Tim Cochran from Thoughtworks sheds important light on what to measure. He highlights 10 metrics that can definitely fall into leading indicators. For example “Validate a local code change works” with a expected value of 5–15 seconds. This metric has a high correlation with the inner developer feedback loop. And it’s hard to argue that a system is inefficient if a developer needs 10 seconds to validate that a local code change works. If the actual value in your org is way less than that, maybe it’s time for a change. A new tooling might be required or improving the build system. For example, a JS shop may benefit from implementing Vite to improve the build time so a local change can be verified faster.
Now, the trickiest part is finding metrics to measure and improve as it’ll be tightly coupled with the workflow inside a company. What Tim Cochran highlighted is a good baseline to try, but I suspect that each company is unique and require different metric to try. What I can tell you with confidence is that total line of codes or time spent inside an IDE are not good indicators of developer efficiency. We’re humans and we should be empowered to fulfill our human nature.
