Developer Productivity?

We can only improve total productivity by improving people and processes. Re: A post from Kent Beck and Gergely Orosz. [cw: “Intercourse”]

The post appears as part of Beck’s marvelous substack, which I strongly recommend¹. The post itself, part one of two is by Gergely Orosz, with part two from Kent coming Thursday (tomorrow, 31 August 2023).

I freely state here that I have not fully digested Orosz’s article and of course I haven’t even seen Kent’s, so my remarks here are about the topic, not about these gentlemen.

I will, however, trigger myself with one quote from Orosz’s half:

Who wants to measure productivity, and why?

This is such an important question to start with. The answer will differ dramatically, depending on who’s asking, and what the goal of the question is. Here are a few common examples:

#1: a CTO who wants to identify which engineers to fire. “How can I measure the productivity of engineers in the organization, to identify the least productive 10%, and let them go?”

First of all, Intercourse² this CTO. Period, paragraph. In my view, this attitude is immoral, and I use that word rarely and with some skill and training behind me³. The article’s items numbers 2, 3, and 4 are a bit closer to reasonable questions. You’ll do well to read the article, and I’ll do well to study it further. I am here now to organize my own thoughts. I propose to touch on these topics:

• Low Leverage
• Proximity to Information
• How Long Should It Take?
• Better Ways to Raise the Average
• Thoughts for Developers
• Final Thoughts: Human Things

Low Leverage

In all the large organizations I’ve worked with, the developers had very low direct impact on corporate success. They were made to work on features chosen by someone else. The features were ill-specified. When completed, the features were not released for a long period of time. There was no way of connecting results from any given feature to the profits of the corporation.

In some situations, such as “Continuous Release”, the time delay is reduced. It is possible, at least in principle, to measure uptake of specific features, but if we did, the decision maker who chose the feature is the individual to be concerned about, not the developer.

Generally speaking, adding or removing a developer has a small incremental effect on delivery, and the more developers you have, the smaller that effect. We note that the effect can go either way. Removing a toxic developer can improve results, adding an incompetent one can reduce results.

In this light, while perhaps your overall development expenses are high, improving the situation by removing or adding developers is fraught. It’s quite likely to have little or no connection to what’s really making a difference.

Proximity to Information

Orosz makes the point that a manager should know how productive her people are, and I agree in principle. I have also met what seemed like a perfectly good manager who was completely mistaken about who the best person on his team was. He had identified, as best,the individual who was most corrosive, who created more defects than the rest of the team combined, and who was being supported by extra work done by the others⁴. The point here is that while managers should know, they do not always know who their best and worst people are.

The further you get from the coal face, the less you know about the miners. Assigning a score to all the developers in the organization is problematical—again, see the Orosz article—and is unlikely to produce either fair actions, or effective actions, at the CTO level.

How Long Should It Take?

Alex produces ten features in a year. Robin produces three. Should we put Robin on an improvement program to bring that number up to Alex’s standard? Does Alex deserve a larger bonus than Robin?

We have no way of knowing. There is no standard “how long should it take” measurement for a feature, even if we were able to factor out issues like the fact that Robin is on several key guidance groups and spends 75 percent of their time in key meetings.

If we do not know how long things should take, we cannot know how productive people are. If we do not know everything about people’s responsibilities, we cannot know how productive they are.

Better Ways to Raise the Average

Presumably the [EXPLETIVE DELETED] CTO claims that the intention is to raise average productivity by removing the bottom ten percent of developers. That may happen but in so doing they will also reduce total productivity, unless those ten percent were pulling in the wrong direction. And how much will the average go up?

Presumably we have a more or less normal distribution of productivity, with the bulk of individuals centered near the mean and a few high end and a few low end. The average will rise, but not much.

If the [REDACTED] CTO were honest, they would more likely admit that their intention is to reduce costs, thus extracting more work out of fewer individuals, improving the situation for the oligarchy at the cost of the workers. You can prove this to yourself by noting how expectations are reduced after the removal of the ten percent. Certainly total productivity has gone down. Surely we will reduce expectations accordingly.

I have never, ever, in six decades, seen that happen.

We can only improve total productivity by improving people and processes, not by reducing head count.

If we need more productivity, we cannot get it by reducing staff. We can only get it by improving the people we have, and the processes we use⁵. Let’s find, for each developer, the things they need in order to be more productive and provide those things. Those things might be training or coaching. But they might be a better computer, more access to the servers, improved software tools such as IDEs. Perhaps they need a more quiet workspace, better lighting, less noise. If we want more productivity from our people, we need to give them whatever they need to be more productive.

Firing people in batches⁶ cannot increase overall productivity.

Thoughts for Developers

I believe that we are currently in a phase where companies are tightening their belts and reducing staff. This is a bit odd, because we are also in a time where many companies are earning incredible obscene profits.

We all know where those profits go⁷. They rise to the top of the organization. They buy the biggest yacht in the world. They let the boss fritter away 44 billion dollars destroying a company. That said, developer pay is near, if not at, an all-time high, and software development is an easier line of work for most of us than digging ditches, doing roofing, or driving delivery vans⁸.

In my article Developers Should Abandon Agile, I offer some thoughts on what developers should do, and a few more possibly interesting notions in the related category Abandon. And of course my readers are aware that I focus strongly on what it takes to be good at developing software, and what it takes to find joy in developing software.

In times of population pressure on developers, I think that developers do well to keep raising their skill level, so as to look good on whatever good (or more likely fiendish) measures management may come up with, so as to avoid the scythe. Generally speaking, quality will out, and even if the scythe does get you, skills will be part of what gets you hired, hopefully somewhere better.

But there’s more to it than avoiding the cutting blade. If you’re in a corporation focused on extracting more work for less money, and you almost certainly are, then you owe it to yourself to be as sufficient to yourself as you can be. That means to enjoy your time in the job, which means, in large part, doing your job with skill you can be proud of.

Final Thoughts: Human Things

I write mostly about technical matters. That’s not because technical matters are most important, but because I enjoy writing about them. In your job and your life, the personal, inter-personal, human matters are almost certainly more important. “No one ever died wishing they had spent more time in the office”, someone said⁹, but while we are there, working and living effectively with our co-workers is important, and while we are not there, living well with our loved ones is important.

The human things are more important than the technical things. I just write about technical things because I can.

Take care of the humans in your life. Let the corporations fend for themselves.