If you're going to worry about software quality, you need to stop talking about developer productivity, and start talking about business productivity. You can't objectively measure the productivity of a worker in isolation. You have to measure whether the productivity of a worker increases the overall value of the business, or whatever goals the business has.
It goes like this:
1. "We need to improve how fast developers release features". Ok, so we throw out tests. Now they're shipping fast!
2. "We need to improve the quality of developers' code". Ok, so we add quality gates. Now they're shipping better code!
3. "The quality gates are slowing down productivity." Ok, so we'll introduce them at earlier stages, shifting left. Now they're shipping better code faster!
4. "The software works, but the customer is unhappy with the product." Ok, we'll focus on giving the customer regular updates and validating the results are what they expect. Now they're shipping better code faster that the customer likes!
5. "The software is now much more expensive than it used to be." Ok, so we...
...and on, and on. Each time, because nobody is focusing on the entire value chain, only a single thing is getting fixed, and it ends up having knock-on effects. It's not enough to perfect one link in the chain. The whole chain needs to be strong, and communication needs to go both directions, constantly.
Actual management is hard! Companies are completely chaotic systems, and every important feature comes as much from the details as they do from the big picture.
Most people are completely unable to work with that, what includes a large majority of the managers on every level. Worse yet, it's never clear if a good or bad result happened because of somebody's work or despite it, so the feedback is completely unreliable and it's incredibly hard for people to improve.
And yet, I've never seen anybody teaching "management" to even acknowledging any of the complexity. (Including famous authors and professors.)
I think W.E. Deming had some very good practical advice that I rarely see actioned. One place I worked, there was an entire volume of Deming's books on a shelf you had to pass to get to the cafeteria. But his advice wasn't being heeded. Why is that?
My thinking is, there's often enough people working for a business that know what the problems are, and can figure out how to solve them. But they can't solve them if they don't have the authority to do so, or their superiors stop them, or nobody cooperates with their attempts. I don't know how to solve that, but it must have to do with agency and cooperation.
I find the concept of "productivity" fascinating. It must be measured in money because (positive) productivity means someone is paying for what you are doing.
And in that sense you cannot measure the productivity of a single person alone, you must measure what people are willing to pay for their output.
If you produce exactly the same as you did last month but nobody is buying it this month (or ever again) it means your productivity is zero. Is that true? Or does it mean your productivity is negative?
Or is it the case that when you work for someone else your productivity can be measured by the salary they are paying you? That would mean that "productivity is in the eye of the beholder". Your productivity as seen by you is different than your productivity measured by your employer.
>If you produce exactly the same as you did last month but nobody is buying it this month (or ever again) it means your productivity is zero. Is that true? Or does it mean your productivity is negative?
No, your productivity has no connection to sales unless your job is in sales. And productivity for individual employees is measured all the time, across all industries.
Your time and output is being paid for by your employer, not the customer (except where they are the same person,) therefore productivity is loosely a measure of the value you create for your employer over time.
Proxies of productivity are measured. what really matters is total net profit over tha life of the work. For sales this is easy to measure, and for production factoriy workers it isn't too hard. But for most jobs it is hard. Even simple acts like greasing machines is hard to measure how it affcts profits (an actountant can do it, but at the cost of an actountant is it worth measuring) for engingineering the measure cannot be made until the last of that product is sold, but we need it up front to decide if we should invest in the engineering.
in that sense everything is a proxy and the word ceases to have any meaning.
This is a class "the whole is greater than the sum of its parts". You're talking about productivity as a whole, everyone else is talking about productivity of the individual parts. The two are related but independent.
Why so complicated?
Productivity per se has nothing to do with sales or employment at all. I can be very productive writing poems for myself.
High Productivity = Spent effort results in progress towards the desired outcome (the product).
The question is: What is the product?
I believe the issue is, that many (software) company are confused about that. Their product is the invoice. Everything else – especially the software sold, is just a means to an end.
You can be very productive writing poems but how do you measure your productivity? Number of lines you write per day?
Similarly in software development it is commonly understood that the lines-of-code is a bad metric for productivity. Some people write many lines while others may eliminate lines from it.
In general "productivity" is about economic activity and thus measured in monetary terms. But that doesn't make it any simpler.
It goes like this:
1. "We need to improve how fast developers release features". Ok, so we throw out tests. Now they're shipping fast!
2. "We need to improve the quality of developers' code". Ok, so we add quality gates. Now they're shipping better code!
3. "The quality gates are slowing down productivity." Ok, so we'll introduce them at earlier stages, shifting left. Now they're shipping better code faster!
4. "The software works, but the customer is unhappy with the product." Ok, we'll focus on giving the customer regular updates and validating the results are what they expect. Now they're shipping better code faster that the customer likes!
5. "The software is now much more expensive than it used to be." Ok, so we...
...and on, and on. Each time, because nobody is focusing on the entire value chain, only a single thing is getting fixed, and it ends up having knock-on effects. It's not enough to perfect one link in the chain. The whole chain needs to be strong, and communication needs to go both directions, constantly.