I want to start off by saying that I don't completely disagree with you, but all of us should take a step back and realize how an absurd of a position this is for us to be in a society.

This immeasurability is inversely proportional to the tangible, real value created. You can, for example, absolutely measure to the dollar the productivity of a plumber and you can easily compare two different plumbers, and see if environmental factors improve or decrease their productivity.

If you own a factory making screws you can unquestionably measure the valued added and therefor productivity of each and every employee. If you have a farm and you hire seasonal laborers to help you harvest, again you can easily measure the exact productivity of each worker, determine if a hot day makes them less productive etc.

Software engineers are a step removed from this in part because the things we make are of questionable value (especially in the extremes). Front-end contract engineers certainly seem to have measurable productivity. If someone can build you a working store front in 40 hours, you can compare this to another one how can do a worse job in 100 hours at the same rate.

But as software products grow more complex and the actual value more vague, then software engineer productivity likewise gets harder and harder to measure. And I think a real question every engineer who has worked at a large company has asked, even if they work their asses off, is "do I really create any value?"

Software engineers, again, are still closer to the side that you can measure real productivity because in at least most cases software itself is important. When you move on to other "office workers", those who are really struggling now, that value again is very hard to measure and therefore so is productivity.

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.

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?

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”.

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”.

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.

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.

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.

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.

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

You can factor in the time (presumably that’s paid for so you should have a real number) and cost of materials (On-site use historical or replacement cost) yourself.

Your points holds more generally though, especially when there aren’t clear prices paid.

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.

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.

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.

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.

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

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.

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.

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

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."

You have to have a great deal of sympathy for the management of software-heavy companies. They've no idea how to manage software development. Nobody really knows how to. It sucks. Oh, well, I suppose there is a way: mind the bottom line, do not over-hire, and have good managers of the old sort: the type that know how to keep tabs on their direct reports without being overbearing. Business schools won't go for that.

It's possible one of Scott Adams's moles was at this meeting, since they seem to be omnipresent and omniscient.

https://en.m.wikipedia.org/wiki/Goodhart%27s_law

Must we keep our most important measures target free? That sounds insane, although I can see how it would improve the measurement.

So the questions is how are we supposed to set targets without our most important measures?

Could you explain this term? I thought i was a native English speaker but this has lost me.

The Dilbert strip has the additional suggestion that the programmer could introduce bugs in order to clear them, in an example of the Cobra Effect.

It's also true that many people have a very different assessment of their productivity than their colleagues do of them. I've seen some pretty massive disconnects there, which usually lead to trouble.

While I do agree that many productivity metrics are useless and even counterproductive, measuring productivity in a useful way is most certainly possible. For example, sales organizations measure sales per unit time for each sales person. I doubt you will find a successful sales organization not doing this.

Or a team player who is good at opening conversations but not closing? (I know, always be closing)

But yes, with a quantifiable and accurate and business-orientated metric, you can measure some form of productivity. It is still hard for most roles in most organisations.

I enjoy team work and I push hard against managers focusing on individual performance metrics because it destroys team work.

* Login time on the VPN

* Number of meetings or some other proxy for activity

* Sales numbers

The first one might be right. People might be spending less time working, when working remotely. The mistake is in assuming that they would be contributing any sort of value if they were in the office and logged in 100% of the time.

The second one might be right too, but again, may not correspond to anything

The third one, if true, probably has less to do with the productivity of the workers and more to do with the economic situation.

But who knows? They may have something real.

I totally disagree. That's the whole point of your manager and reviews.

In addition, JPMorgan isn't just programmers. It's a lot of people who talk to people and process paper--a LOT of paper. And they can quite clearly measure how much paper is being processed per person.

> Employees always figure out how to abuse productivity metrics.

That's a different problem from being able to see that productivity is up or down.

Now, the larger question is whether productivity is down because of work-from-home or productivity is down because the economy is in a complete shambles.

Most managers will think an employee who spends 10 hours working and 30 hours schmoozing/promoting their work is more productive than someone who spends 60 hours grinding the tasks given to them.

It's a complete sham--up until the moment it's about to fire you.

Yeah, I've been in the "Look, that deadline is HARD. If you don't figure out how to do something useful by it, the whole GROUP, including me and you, are fired. So, are you gonna figure something out or should I fire you now and get someone else?"

That can wake you up, reeeaaaal quick.

> Most managers will think an employee who spends 10 hours working and 30 hours schmoozing/promoting their work is more productive than someone who spends 60 hours grinding the tasks given to them.

And you know what? The "schmoozer" might actually be more productive.

One of the articles on HN recently was about how senior people tend to avoid work that might get thrown away.

"Grinders" are useful, but they can also go grinding in the wrong direction or keep grinding on something that no longer needs to be done because conditions changed and they aren't paying attention. This is especially true if they get too irascible so nobody wants to talk to them.

The "schmoozer" might see that the assignment given doesn't quite match up with what the end customer (either internal or external) actually needs and adjust things appropriately. Or, perhaps, just delivers something "close enough" but takes a lot less time and makes the recipient happier.

As I became increasingly senior I spent far more time "schmoozing" than getting concrete engineering done.

The only sane reply is: "You can't fire me, I quit". First of all, this working env is toxic. I don't need this kind of stress and I can freely quit because I have life savings, like any other sane person. Second, now that deadline becomes impossible without me, not merely hard, good luck to the rest of the team. Third, I might not quit if you apologise right now.

But then again, I'm in Europe, where we have more rights than the Americans. YMMV.

And in one HN comment the whole problem with late stage capitalism is laid bare.

As an engineer in general how can you quantify the value of maintenance? On paper it's just a cost and it's impossible to know what would have happened without it.

The worst strategy is just to measure easy things like story points or number of tasks completed because it ruins the work culture. In those cases you're not going to take time to review pull requests carefully, advise colleagues, propose new projects or work on difficult tasks. It seems impossible to measure these, at least to me.

In a situation where workload is at least sort of randomly distributed, which it normally is given time, there’s no other good explanation for statistical deviancy than simply less “work” being done.

But again, this only works for detecting problems. As you point out, and I agree with you, as soon as you attempt to measure “change in productivity” you’re on very thin ice.

If I hire painters, I can tell if they’re doing a good job by looking at it. I know what’s taking them so long. They’re using slower drying drywall compound, or they’re having to mask off because they’re not good with a brush.

There are fields of work where it’s easy to gauge productivity, but software development is not one of them.

It's easy to make a job look good for a day, but on some jobs if you skip the prep work, lining, filling, priming, undercoat, additional coats, clearcoat, and finishing the paint job is going to look pretty bad after a year. You can't tell how good a painter is unless you know a bit about painting things.

The same is true of software. In order to know if a developer is productive you really need to know quite a lot about the domain they're writing software for.

I manage a team of developers / analysts and it's straightforward (though not always easy) to measure this over several six-week blocks of time for the team. It is not, however, easy to measure it for any single developer or analyst, and there's a lot of variance when you try to look any more granular than the team.

I suspect it's doable for small groups that work together. Or even larger groups. (I have no experience here.)

But for individuals? I agree. No shot.

Yes, and working from home makes it even easier. Your post basically says that any measured productivity gain from WFH can't be trusted but I don't understand why it would apply to a measured productivity decrease.

Targets aren't the same things as measures. Measures of productivity are easy, but targets are not.

For example, for a sufficiently large group of people (e.g. all young developers at JP Morgan), you can measure their productivity with how many lines of code they write on average. As long as you aren't using lines of code for performance evaluation, there is no reason any developer will perform needless large refactors or find other means for increasing their delta.

Edit: changed metric to target

I’ve solved problems with 6 lines of code that took me a week to think of. Other days I write 600 lines of code.

I would argue that the former 6 lines I wrote is much more productive than the 600 lines.

On the other hand, perhaps people are indeed writing the same old code that they always were, just writing less of it.

So lines of code are not a good metric. Average number of features/user stories/tasks delivered may be a decent metric (at the group level, not for individual developers), as long as it doesn't become a target. Delivery VS estimate could also be OK, in the same way.

If people can abuse your productivity metric, then it's a bad measure of productivity - not a fault of the worker.

There are many nuances to the English language that are difficult for non-native speakers to pick up.

Being condescending is bad, but being condescending whilst also being clearly wrong is doubly so. Get out.

And I think you’re wrong. I think your parent post agrees with you. Not every conversation includes the requisite specificity of language to make declarations of perfect understanding of original writer’s intent.

We will need OP to confirm.

I don't see how the term abuse means that the parent doesn't agree?