Developer Productivity

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.

Measuring Developer Productivity

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?

Inputs to Developer Productivity

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
• Talent
• Technology

Business Practices

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.

• Excessive meetings. Remove all but the bare minimum routine scheduled meetings. Do not involve more than the required participants in a meeting. Invite people to leave meetings they are not providing value to or deriving value from. Restrict meetings to particular times of day so developers can plan their work around those known interruptions. Management should avoid scheduling same-day meetings with developers. Let them work. However, developers should be free to have short, ad hoc meetings with other devs to coordinate and unblock when it is holding up work.
• Corporate red tape. Procedures that require forms to be filled out, approvals obtained (especially from non-developers that have little understanding of what they're approving), boxes checked and documents generated (especially when they are unlikely to be read) need to be eliminated to the extent humanly possible. Not only does this distract from valuable work and tie up attention, it usually requires human interactions that interrupt concentration and immersion.
• Micromanagement. People who are not developers dictating to developers implementation details, tool choices and priorities that do not align with what is needed in the real world for best results in the software developed, is counter-productive and requires constant interruption.

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.

Talent

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:

• Invest in hiring. You don't need to exclusively hire top-tier, experienced, expensive talent. But hire at least one that you can trust to make good architectural and directional choices.
• Invest in mentoring. When you hire for experience, look for those that can also mentor. Those lead devs can then help cultivate a killer team that starts with junior and mid-level developers that learn from the experience of the lead developers.
• Listen to your developers. If your devs are unhappy, you risk losing them and all the domain knowledge they've acquired while working for you. That is not to say that you should believe every complaint and take it seriously. If one person complains about something, it may be nothing more than idle, disgruntled noise. If multiple people are complaining about the same issue, you likely have a problem that warrants a remedy.

Technology

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:

1. Budget for experimentation. If a dev finds a new tool and insists it will net a productivity improvement, let them implement a proof-of-concept (POC) or trial usage with a small group. Limit the POC or trial to a budget in time and/or expense. If the result will provide an improvement that outweighs the cost of change and migration, run with it. Even it if it doesn't pan out, your devs will appreciate the room to experiment if you make the parameters clear.
2. Budget for innovation. Sometimes technology does not exist to solve a problem. And devs build technology. If a gap exists that is important enough to solve and your devs can build a solution, budget for a project to solve the problem. Allocate a percentage of their time to work on it if warranted. Even if the problem proves insurmountable within the allotted budget, again the devs will appreciate the opportunity to solve a problem.
3. Invest in open source. If your devs wish to innovate on a problem, and that problem is not a part of the business' core competency, let your devs open source the software without undue friction. It provides an opportunity for collaboration with other organizations that may want to use the solution as well. And it can spread the load of maintenance of the software. And it is good juju. Your organization almost inevitably uses open source software. Be a net benefit to the world by contributing back. Your developers will get satisfaction from it, be happier and more likely to stay where they are.

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.

Technology for 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:

• Individual workflows. This is sometimes referred to as the inner loop of software development. The technology used here includes the IDEs developers use and their local development environments. It includes the programming languages they use and the libraries available for those languages. And it includes the services that are used in their individual workflows, such as GitHub or some project management software which are the interface to the outer loop, but nonetheless a day-to-day part of their inner loop. There are always incremental improvements available in this area, but most of the big improvements are available in the interface with the outer loop or squarely in the outer loop. Backstage is a great example of a technology that has become very popular for leveraging company-wide improvements to make them readily available to every individual contributor. It helps break down silos and improve collaboration.
• Remote delivery. The software that developers build usually has to be deployed and managed on remote servers. Whereas developers have been building software on workstations for several decades, the advent of the cloud along with distributed and decentralized computing is relatively new. As such, there is significant room for improvement and innovation in this area. For this reason, DevOps teams have exploded in size and platform engineering has become its own discipline - all for the purpose of providing a self-service developer platform for delivering their software.

Software Delivery

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

Threeport is a software layer that manages delivery including all the following parts:

• Cloud infrastructure for runtime environments. This includes the servers, networking and identity management that is needed to provide the environments where your software runs.
• Kubernetes clusters. This is the interface for software delivery. It is the API that is called to spin up, modify and remove applications.
• Manged services. This includes the cloud infrastructure that is a part of your app stack, including managed databases and object stores.
• Support services. Virtually every app requires common services installed on Kubernetes to manage in-cluster network routing, TLS termination, DNS records, secrets, observability and more.
• App delivery. All the workloads that comprise your application must be delivered to their runtime environments.

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.

Qleet

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.