«How productive are my developers, really? Can this be measured somehow?» a friend of mine, the CEO of an InsureTech SME, asked me recently. «I mean, ‘if you can’t measure it, you can’t manage it,’ as W. Edwards Deming once said.»

I understand the concern: Unlike a copywriter or a salesperson, whose activities can be easily understood from the outside, the work of a programmer often remains obscure. Someone might spend a week on the task “JIRA-494 — refactoring auth connector,” without any visible change in the application. «We’re making the application more secure and easier to maintain,» the developer tells me as a justification. “Was any work actually done?” some wonder with a nagging feeling in their gut.

«Well, it’s not that simple…» I begin — and am immediately interrupted by the CEO: «Couldn’t we just count the lines of code?»

That sounds obvious — and would be so simple. Yet, it quickly becomes clear that this is not a suitable measure. It would be like judging Vincent van Gogh’s performance by the number of brushstrokes he made.

Code is bad. It rots

The “written lines of code” measure merely quantifies the amount of typing a programmer does. And in the age of AI systems, like the autocomplete function in Microsoft CoPilot, not even that. (See my earlier blog post on the subject.)

A productive developer is characterized by much more than nimble fingers. Because good code…

• fulfills the desired tasks

• contains no errors (visible and hidden)

• can be expanded with little effort

• is understandable to others

• is sufficiently fast

• contains no security vulnerabilities

• One could even say: The less code necessary to meet the above criteria, the better. Jeff Atwood, the founder of Stack Overflow, the most popular Q&A platform for developers, saw it the same way:

«Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted.»1

More code, more problems, one might summarize. Consequently, the renowned computer scientist Prof. E. Dijkstra speaks of “Lines of Code spent.” Every line of code means effort — and we want to keep that as low as possible.

So, do we need to completely ditch the number of lines of code as a metric? I wouldn’t go that far. Just as the sound of a bassoon from behind a closed teenager’s room door is an indicator that my daughter is practicing, lines of code are at least an indicator of a developer’s activity. Therefore, in our internal performance monitoring tool DevFlow, we display this metric per team and developer. But it’s one measure among many: participation in code reviews, delivered story points, quality of code reviews (verified by ChatGPT), and so on. And none of these measures should be more important than the above-mentioned criteria for good code.

Press enter or click to view image in full size

DevFlow is our process analytics tool

Also, in the due diligence of development teams that I occasionally conduct for clients, the performance in lines of code is one of ten parameters that I include in my assessment. It’s an activity indicator, but nothing more.

My friend, the CEO, was getting nervous: “How can I find out if my development team is delivering the hoped-for performance?”

Even though there are other attempts to quantify the productivity of developers — such as the Function Point Analysis or the DORA Metrics — over the years, I have come to the same conclusion as Martin Fowler, a highly respected computer scientist:

«I can see why measuring productivity is so seductive. If we could do it we could assess software much more easily and objectively than we can now. But false measures only make things worse. This is somewhere I think we have to admit to our ignorance.»2

No quantitative metrics does not mean flying blind

As tempting as it might sound to handle quantitative metrics, focusing on individual metrics can do more harm than good. But that doesn’t mean we are flying blind. If we stay close enough to our developers by, for example, regularly participating in sprint demos and maintaining informal contact, then the team’s performance becomes intuitively perceptible. Just as my wife intuitively senses my performance as a spouse without having to keep track of the number of trash bags I take out each month.

However, it’s not always possible to build such a close relationship with one’s development team. Especially as a CEO, time is often better spent elsewhere. Then it’s necessary to have the right people on the team to whom this assessment can be delegated. In the case of our company, mühlemann+popp, I take on this part, and my business partner Markus Popp relies on my judgment. If the necessary experience and expertise are lacking in-house, external help is available. With mühlemann+popp, we repeatedly conduct tech assessments for partners and customers, in which we neutrally and objectively assess the performance of development teams based on our expertise.

Debunking the Myth

To foster high performance in development teams, it pays to focus less on quantitative evaluation approaches and more on effective management methods: hire experienced staff, provide capable technology, ensure motivating tasks, and ensure good project management with credible, realistic goals that the development team supports.

“And what about William Edwards Deming’s quote: ‘If you can’t measure it, you can’t manage it’?” my counterpart asked.

This is not quite true. That is, the quote does exist. But it is incomplete. The full statement is actually: “It is wrong to suppose that if you can’t measure it, you can’t manage it — a costly myth.”

Deming’s statement was that metrics are important for making management decisions. Yet, there are many things that cannot be precisely measured and yet still need to be managed. One of these is the performance of developers.