By Richard Lander, CTO | May 31, 2024
Developer productivity is critically important to every organization that develops software. The software services offered by a business are commonly an incredibly important differentiation lever. So maximizing the return on software development investment is at least important, and often the determining factor for a company's success or failure.
Collecting metrics on developer productivity is notoriously difficult. If you're collecting data points around lines of code written or number of commits merged, stop. Some of the best changes to a software project's codebase reduce the number of lines of code. And commits merged is similarly useless. Any given commit can vary massively in its actual value to the software project. If you reward developers based on the number of commits they produce, you incentivize rushed commits that are not well researched, designed, documented or optimized. You also increase the natural overhead that comes with each code commit, such as code reviews by piers.
The takeaway is that it is usually quite futile collect metrics immediately concerning the development of software. It's a lot like measuring the number of words written by a fiction author. If an author produces a novel in 8 weeks, but the book sells 20 copies, how productive was that author? In contrast, if an author takes 12 months to write a book that sells 100 million copies, they are vastly more productive in terms of market value. When the quality of the output is so integral to its inherent value, you can't measure productivity the way you would with a commodity-producing farm or factory.
What you really want from your developers is well designed and implemented software, produced as efficiently as possible. So how do you measure that? You measure it primarily by outcomes. With a novel, you measure copies sold. With software, it depends on what the software's intended use is. Work out what your software does and measure how often it produces that intended result, and measure how much your user base is increasing or decreasing.
Now you have the most important barometer of how successful your software development is. Now you can determine the effectiveness of your efforts to improve developer productivity. Just keep in mind that holistic changes that improve developer productivity take time to produce valuable results. So make changes deliberately, from first principles, one at a time, and log those changes. Then compare them to your barometer on the value of your software as measured at the users of your software.
Now, we can work backwards into the areas that we know can improve developer productivity. We have to start with the inputs that are certain to have a positive effect. Then be patient and watch the barometer to see how positive the effect is in reality. Use that feedback loop to inform future changes.
So what are those areas that matter? And what do we know will help?
These are the areas you should start with. If there is a general order of importance to these areas, they are listed in order of least to most important.
Business practices around software development are the least important factor because is the easiest to get right. However, if it is botched, it can demolish developer productivity. I have little sympathy for organizations that botch this factor since, when it is a mess, it is usually a top-down cancer that good developers should run away from as fast as possible.
Here's the no-brainer. Developers need time and space to get their work done. If your developers are routinely interrupted, their productivity will suffer. Quality software development requires time for individual contributors to immerse themselves in a task and maintain their concentration for extended periods. The following are the most common ways developers are interrupted and distracted.
When these things are a problem, the core issue is usually that non-contributors and under-performers are inserting themselves into productive processes to retain relevancy. This is toxic to productivity and must be eliminated or at least mitigated at every opportunity. We will not dive into HR hiring and firing practices here but suffice it to say for now that HR needs to facilitate this effort.
Again, we won't delve into the granular HR concerns around hiring good talent in this post. But it must be said that talented developers must be present for good work to be produced. This is another no-brainer that provides a good staring point. You can hire good devs. You can cultivate good devs. And you must retain them.
Each developer can make an immense difference with good design and implementation choices. This is a lever that cannot be understated. Poor choices that have far-reaching effects can bog down future productivity in ways that can only be understood from hard-earned experience. With that in mind, here are some critical points to attend to:
The most important factor is technology. That is what developers are dealing in, after all.
Technology trumps business process in importance because technology fundamentally exists to replace toil and human work with software. Virtually every area of routine human toil and business process is an opportunity for replacement with software. The only question is whether the technology exists to supplant it.
Technology trumps talent because using a piece of software that was built by top-tier developers elsewhere - that can be paid for or used for free - removes the need for you to have that talent on your payroll.
Developers use software technology in almost every part of their work. As such, they are usually pretty good at identifying and evaluating the use of such tools. When they discover some software that improves their productivity, listen to them. Encourage optimization and improvement. However, over-experimentation can induce churn that does not produce a net benefit. An entrenched piece of software that is being used widely in an organization can be expensive to replace. Your people need to learn the new software and migrations need to be made when changes to tools are made.
Here is a framework that will help:
So far, we've covered the three areas that primarily affect developer productivity. I've asserted that technology is the most important input to improving that productivity. Next, let's dive into the technology that can improve developer productivity.
What technology can improve a developer's productivity?
To answer that question, we should look to the places your developers toil the most. The answer varies from one organization to the next but there are some constants that are prevalent. We're going to break this into two parts:
Any time your developers have to submit a ticket or interface with another team to get a thing done, their productivity suffers and there is an opportunity to leverage software systems to boost output.
Software delivery is just such an area. If your developers have to interface with a platform team to get a remote environment made available for development, testing or QA, there is much room for improvement. If your developers have to interface with another team to perform a new deployment of their app for testing or QA, there is much room for improvement. Even worse, if you devs have to dive into configuration repos filled with deployment configs that are written in unfamiliar languages and executed by unfamiliar tools, there is massive room for improvement.
Any time you see config management toolchains in heavy use by humans, you have significant room for improvement.
10 years ago it was very common for config management tools like Ansible, Chef and Puppet to be used to deploy software to servers. It started out as a boon to delivery efficiency. However, the number of apps under management grew, as did the sophistication of those apps as distributed computing took off. As the number of apps and servers under management grew, the burden on teams to manage this software delivery grew. Then Kubernetes arrived to provide a software layer to manage the delivery of applications into clusters of servers. That abstraction immediately boosted the number of apps and servers that could be managed by a relatively small team.
Now, as application sophistication and volume have both continued to increase apace, we have accumulated a new config management layer atop Kubernetes with tools like Helm and Kustomize. We've also largely continued using config management tools like Terraform to provision cloud computing infrastructure, both for the runtime environments and for services that form part of the application stack itself.
This presents a massive opportunity for improvement in developer productivity. Too much time is spent by developers and DevOps professionals wrangling this new config management layer. Claw back the time your practitioners spend in this area and you gain back additional development time on the quality and stability of your software. Opportunity costs are difficult to measure, but they are a real factor in your success.
Threeport is a software layer that manages delivery including all the following parts:
Threeport orchestrates the delivery of all these components and dependencies so that you can rely on a control plane to elegantly provision and connect all these pieces without having to dive into endless templates and config files to wire it all together.
Threeport is open source and available for you to try out. Check out the releases page on the GitHub repo to download the Threeport CLI tool, tptctl. And refer to the documentation for instructions to get started.
If you find Threeport to be useful in helping manage your software delivery, and would like to use it without having the overhead of managing Threeport itself, Qleet offers managed Threeport control planes for you to use so you can focus on your business' core competency.