> You can, for example, absolutely measure to the dollar the productivity of a plumber and you can easily compare two different plumbers

I'm curious about this idea.

What if plumber A shows up, quickly fixes something using existing, on-site materials, and ends up charging much less (no parts + 'quick' labor), and then the plumbing breaks again in X months.

What if plumber B shows up, takes more time and replaces a part of the plumbing, and ends up charging more (part(s) + more labor) but then the plumbing lasts for Y months, where Y >> X?

Which plumber is more productive? How does one convert the productivity to dollars?

Doesn’t happen to the same degree as in software. With plumbing or painting, yes there are good jobs and bad jobs, but if the water gets to where it’s going and there’s no moisture, you’re pretty much done. If the paint is on the wall and not on the ceiling or the trim, and you can’t see roller marks, it’s a good job. With software, there seem to be endless layers of nuance between good or bad, finished or unfinished.

Also, it should take X hours to paint a room of Y size with this many windows or doors. There are clearly established timelines for a job and any big deviation from that will get you fired (or not hired again by the same builder). There’s no “due to this manager’s lack of experience with agile, a project that should have taken 2 weeks took 4 and a half months, and the test coverage is poor”.

Doesn’t happen to the same degree as in plumbing. With front end or back end, yes there are good jobs and bad jobs, but if the data gets to where it’s going and there’s no bit rot, you’re pretty much done. If the data is in the db and not on the paper forms, and you can’t see it decrypted at rest, it’s a good job. With plumbing, there seem to be endless layers of nuance between good or bad, finished or unfinished.

Also, it should take X hours to code a feature of Y size with this many fields or inputs. There are unclearly established timelines for a job and any big deviation from that will get you fired (or not hired again by the same builder). There’s no “due to this plumber’s lack of sobriety with the world, a project that should have taken 2 weeks took 4 and a half months, and the connections on the joints are poor”.

With all due respect, you probably know more about software than plumbing, maybe leading you to simplify a bit. Because the same logic could be applied to plumbing, but any plumber might see more variables, the way you do with software.

That is another distinction. All the example jobs do routine, repeatable things. Everything a programmer does is either novel or trivially replicable. There is no equivalent to "painting a room of certain size", to do that you use a copy of already existing painted room.

It doesn't happen as much in plumbing or painting because these fields have not had rapid change in the last few decades, so common practices have stabilized. Plumbing also has standardized code and inspections which pretty much make sure that everyone is doing the same thing the same way. And still there are differences in quality. Look at what two painters will do to a piece of shitty material like an oil-painted unprimed piece of plywood. One will sand it down to the wood and prime, the other will just slap a coat on top, and you'll have flaking in a few months.

Whichever one earns more dollars is more productive in terms of dollars. If you want to do this right, pick a good metric (plumber dollars is fine), then optimize your workforce for that metric. Do not reward them for that metric or it will be gamed. Consider other metrics that are important (e.g. customer satisfaction) and set constraints on the processes that set a standard that must be met.

Not objective, not right 100% of the time, but let's not pretend its impossible to improve processes with some sort of goal in mind.

Quality is the conformance to requirements. If you (the client) wanted a quick and cheap solution then A is for you. If you wanted a robust and you are willing to pay the premium to get the B, you're in luck!

Mega big banks in the USA suffer from tech debt A LOT. The number one reason for operation disruptions is software errors, and with a large difference to reasons 2-3-4.

An additional point could be that large USA banks have a higher (imho) ratio of sociopaths in their ranks. Perhaps the sociopaths lost the ability to whip their minions, and the minions started working under normal/human speeds 40h a week instead of 60-70h per week that is the typical expected work while under the influence of a sociopathic boss.

Also lets not forget that JP Morgan CEO is THIS guy: https://www.theguardian.com/us-news/video/2019/apr/11/jp-mor...

I think that, although imperfect metric, the bottom line will speak of performance. I take it that there are multiple criteria that affect the bottom line, but the management of JPM cannot be trusted, again, sorry for repeating, is not the most decent in the planet.

Edit: apologies for the rant-y beat down of the mega-big US banks, but yeah.. not sorry really.

You are conflating very different issues. So yes, it does come across as a rant.

My perspective, as someone who worked for JPMorgan in technology for 8 years, and for several other banks, is that JPMorgan is way above most other banks in the quality of their systems and their dev teams.

Likewise the top management. Jamie Dimon is very impressive. You don't get to stay CEO of a bank with 250,000 employees for more than 20 years without being seriously good at it, very consistently.

One thing that has stuck with the after many years of working with IT is that the big projects with resources to spare, the few that really gives you time to do the work properly for once, are often the one that ends up with the most tech debt.

It is completely contrary to my own feeling that debt is created by external pressure to deliver too fast. I can see why that would create perverse incentives should a project manager make a similar observation.

Great art breaks constraints, but there is this symbiotic relationship where art is nothing without constraints. I'm starting to think there are similarities with other creative endeavours too, which I absolutely consider programming to be.

Not sure where I wanted to go with this, just reflecting on your rant with one of my own.

What I’ve found over the last 20 years: Tech debt scales with amount of code written, regardless of other factors.

If you write the minimum amount to validate the business need, you have minimum debt. :)

That isn't productivity, productivity is value/duration.

You're absolutely right, but in "Agile" teams this is exactly how they measure productivity: story points (cost)/sprint (duration)

And that is exactly why management shouldn't be looking at or comparing burndown charts. It's too tempting to see IT as a cost centre instead of an enabler.

Define value. Now that's a rabbit hole. Marxist definition? Ricardian?

>The question that we need to ask more often is, if productivity is so hard to measure, maybe it is possibly because we might not be creating as much value as we have largely tricked ourselves into believing we have.

at a very low level productivity is hard to measure because it's tacit and implicit rather than explicit. The reason why we can measure the productivity of a business is because it responds to price signals and you can put a literal number on what they put out.

You can try running some sort of market scheme within your company but at some point the trade-offs are bad and it adds too much complexity and creates strange incentives.

For software in particular if anything the opposite of your assumption is likely true. It adds a lot of value without necessarily being able to put a price tag on it. It's pretty hard to measure what wikipedia or vim is worth in terms of productivity as long as they're not charging, but that doesn't mean it's not worth anything.

This. The productivity of a business is its ROI, roughly its profit + reinvestment. The productivity of a salesperson is also easy to measure: sales / compensation and travel costs. It's much harder to measure the productivity of an individual employee who is not a salesperson or directly supporting sales. Some are rockstars, and these you know when you see them. But the rest... it's harder to tell. Metrics can only do so much, and often they are easily gamed -- they just aren't directly related to the bottom line because these aren't salespeople, but you can't only have salespeople either. Take sprints: if you really want employees to hit every sprint then they'll work hard to hardly load their sprints. As you say, there isn't really a market inside a business, so it's hard to just look at the "bottom-line" for every non-sales force employee.

> The productivity of a salesperson is also easy to measure: sales / compensation and travel costs.

It's not that simple, because most companies don't perform inter-departmental cost accounting. A salesperson might seem to be very productive, while actually selling made-up solutions that are very cost-intensive to implement. To get a real number on how productive they are, you would need to measure:

([sum of sales * price] - [sum of solutions sold * implementation cost]) / compensation

or even:

customer price * weighted average of per-deal profit margin / total compensation

The cost to implement isn't added value. This kind of internal debiting would also change how management looks at IT. If they can solve the problem for less than the estimated cost by the salesperson, they're turning a profit. If they're taking longer due to "science fiction" products being sold, the blame lies squarely with sales. As it is now, salespeople are mainly incentivised for units sold and total price for deals made. You can be a rockstar salesperson while simultaneously mainly causing huge problems downstream.

The real problem isn't measuring the productivity of doing work in its entirety. Installing plumbing is a job. Since only one person is doing the plumbing and that person only does plumbing you can measure the productivity of that job and attribute it directly to a single person.

Once you have a group of people all working together on the same job or the inverse where you have a single person do a variety of jobs everything is different.

You split the big job into smaller jobs and distribute them to people. Some jobs are easier and bring in more money and therefore are more "productive" than others. But all jobs have to be done, no matter how productive they are. So you end up handing easy and difficult work to people. When you start to measure individual productivity of each team member you start noticing that there is a huge variance in productivity. Some people are "useless" while others are highly productive. When you remove the "least productive" people from the job then you notice something odd. Suddenly the productivity of everyone else goes down as well. Your productivity measurements were actually just measuring the way you distributed the jobs.

I remember a machinist talking about how he spends all his day fixing his coworkers mistakes. They kept breaking $100 tools (tool as in endmills) which jammed the machines and he's the only one who did the thankless job of making the machines usable again. He made fixtures that his coworkers broke and then he made them again.... Oh and he had a quota of how many parts he has to make per day. After all, measuring the productivity of a machinist should be pretty easy. Just count how many parts he makes per day. Of course the coworkers always exceeded the quota while he was always well below the quota.

"This immeasurability is inversely proportional to the tangible, real value created".

Although I understand your view,Financial sector and banks in particular is a very regulated sector which means that significant number of people working there have their job almost entirely related to making sure the company comply with the rules from the different jurisdictions. From your perspective, they do add no value to the company ( actually there are cost center) but are crucial to ensure company can operate legally. To add an additional layer of complexity, new rules from different countries, authorities, committees are updated/ amended quite regularly ( last one is the LIBOR demise which will have a huge impact on the market where no clear rules,have acknowledged nor agreed). So even you would try to quantify those costs ( legal issue with new rules implementation which lead to update the system or create one from scratch while making sure this will comply with internal task,etc...), it is quite difficult to assess what is the optimal allocation the company needs to allocate. As an illustrative example, it took 2 years to validate some components of the google cloud features (some are still pending) because of all the intetnal rules set out.

More globally, yes there are people adding no value to the company but the can be hardly spot on from top management view.

There is a big problem in knowing when to measure and what to measure. For example, today my work looks to have similar value to the work of my dog Mr. Biscuits, yet I cost 10x. However, move to tomorrow and it turns out that Mr. Biscuits' code has locked up the cluster and Q3 results are gone. Suddenly I look cheap (I am cheap, but that's a different thing).

Also there is zero agreement on what is good; maintainability, robustness, ease of use -> all subjective at the minute.

> This immeasurability is inversely proportional to the tangible, real value created.

I don't think that's true at all. Certain kinds of value are more easily measured, sure, and if that's all you mean by tangibility, what you say is a rather trivial tautology, but there's times when the value is real and tangible and easily qualitatively described (e.g., reduced workload), but tricky to measure because to accurately measure the increase you'd have to measure against a set of hypotheticals (e.g., cost/performance using best alternative of continuing with the status quo ante or competing automation options, including alternative custom builds.) For certain types of value, this is irreducibly true for many of the same reasons intellectual work is well established to be difficult to estimate accurately (this actually converges to an identical reason when what you are doing is building automation to support intellectual work.)

And even when productivity is measurable, it's often not easily measured at the time of delivery ; where the problem is measuring hypotheticals but the only problematic hypothetical is performance with the software, it may take considerable real use before the actual value is clear.

But, it also can be unclear the value of any individual contribution even when the aggregate product value is clear. Telling the value of what the team delivered is different than trying to peel out the value Bob created.

So you actually believe that if we imagine two plumbers A and B doing exactly the same jobs at exactly the same speed, A charging 70$ an hour and B 35$, A is twice as productive as B ?

It's in line with GDP based reasoning but that's generally done on aggregated data which tend to smooth out these kinds of oddities. As a direct comparaison, it is probably at odd with what most people envision when they think of productivity.

Incorrect. A plumber can spend 10 minutes to fix a leak, but the same plumber can spend 4 hours on apparently the same leak but a slightly trickier one. The same for farm - how much of the output depends on workers and how much on the environment and other factors?

> But as software products grow more complex and the actual value more vague

most popular software tend to decrease in quality with time... engineers are just looking for something to do and add stuff that can sometime be of negative value

This misses the mark by quite a large margin. It's hard to measure the "productivity" of an individual who worked on the polio vaccine, that doesn't mean that it was a worthless product.

The fact that productivity is hard to measure has very little to do with the value of that work, but rather the difficulty of drawing boundaries around people, objects, and time in the functioning of a complex product.

You cannot measure the value of a software engineer without assessing how their work impacted the work of other people, whether it needed refactoring in the future, whether it took into account future requirements that wouldn't be known for five years, etc. You can't even do that with plumbers! One plumber's work may fail in 10 years while the other's is going strong 20 years later, and you may have thought the first one was more "productive."

Another complexity with measuring software productivity is the value of reliability and maintainability which can take years to manifest. Also there is the multiplier effect of having a team player who brings up the whole team’s productivity but might not be obviously measurable.