Developer productivity is not a bad thing – but low developer productivity is not what's holding you back.
Behind the industry-wide interest in coding assistants there's a hidden assumption that the bottleneck for industry profits is developer productivity:
On the surface this makes a lot of sense:
In most tech companies most of what most people do is coding, managing people who code, monetizing the code they wrote, etc. Wouldn't it be great to have more code faster and at the same cost?
Grab a coffee with a senior programmer, ask them quietly, and chances are they'll tell you robust, creative software development at scale will be achieved in a couple of quarters, something that has been true for the last sixty years or so. The median company's development capabilities aren't great.
But a second look at the hypothesis shows some problems:
Developers aren't expensive these days. If developer productivity were a bottleneck companies would be hiring as many developers as possible.
Grab a coffee — or something stronger — with a product manager and they might tell you, late into the night, that the business impact of most code is generally on the low side of expectations and often not even that.
If not developer productivity — if developer productivity isn't fantastic but it's not the main factor limiting competitiveness — then what is?
I believe the bottleneck is upstream of coding, in the depth of the institutional expertise about the aspects of the world the software is meant to help with informing product and feature design:
You can think of it in this way:
Code expresses and implements an idea.
The idea is an incremental improvement grounded on a given understanding of a market, technology, behavior, etc.
The further behind the state of the art is the starting point of an idea, the less likely it is that it's something that can be coded into something truly innovative.
It can be even simpler than that: Developers working in a domain — unless they are writing software for other developers — have an increasingly impressive set of tools, but they aren't going to have a sophisticated understanding of the problem. This isn't a criticism. Understanding the nature and constraints of a problem, what has been tried in the past and what was learned from those attempts, is far from trivial in any domain.
Yes, we all know that good development begins with understanding the user. What's less commonly acknowledged is the impossibility of understanding a user with years or decades or experience doing something unless there's an equivalent reservoir of experience inside the organization.
And if institutional expertise is the bottleneck, then investing in institutional expertise has the highest ROI.
I've written before about how a high-expertise organization looks like. It doesn't need to be "better at having ideas" than its competitors, nor have more productive coders, but even average ideas implemented by average coders, if beginning from an advanced enough knowledge frontier, will have an advantage that no amount of coding productivity can replicate. Developer productivity is how fast you move; organizational expertise determines how far you can go.
By all means, if your developers' productivity is harmed by something easy to fix, fix that. But you won't overtake your competitors by squeezing a few extra lines of code per dollar from your developers. You'll get better results by helping them, and your organization, have a more sophisticated understanding of what they are coding for.
(Originally posted on my blog.)