[strulovich]

Ok, but then what is a way to do it?

The text gives an example to the core problem, and to argue differently requires thinking around it.

In practice. I’ve seen many attempts at measuring productivity, but once you dig into them, you see they are just abstraction mechanisms above something that is similar to lines of code.

I have yet to see an idea that sidesteps the core issue described in this post. Also, it applies to many types of work, and software is not unique in any way.

[bruce511]

Happy Customers.

All other measures are a proxy for happy customers.

Actually, happy customers is also a proxy (the real measure is profits) but measuring profits directly (in the short term) can lead to decisions that have adverse long term effects. It's too easy to increase profits in the short term by avoiding long-term expenses.

So, if you're in the business of software, the goal is happy customers. (And I use the word Customers carefully here. Not just Users who pay nothing, but Customers who spend money.)

In a business context, it's really the only thing that matters. But, of course, it can be hard to measure (are they Happy?) and relies on multiple disciplines. Production (coding), Marketing, Sales, Support, Documentation, Training- all need to be working well to make it work.

Ultimately if the big picture doesn't lead to Happy Customers (again, I stress, in a businesses context) then no-one is "being productive."

[Cthulhu_]

While customer satisfaction is a better (albeit murky) metric, value generated / profit is a better one ultimately. Of course, measuring developer productivity is a means to that end; how much did or will it cost to reach this value generated?

Anyway there's this adage that once a metric (like productivity) becomes a target it ceases to be a useful metric. But this doesn't seem to apply for value / revenue much, so I suppose it's good to keep an eye on this vague productivity metric.

[hammock]

It’s demand. How much demand is there for your product

As the other commenter pointed out, happy customers means nothing if they aren’t actively paying you

[n4r9]

Arguably the business is aiming for Paying Customers, not necessarily Happy ones :)

[bruce511]

I chose happy for a reason :)

So the business is chasing profits. In the short term that means customers paying money - any will do (happy or unhappy).

But in the long term, happy is the key. Happy customers are the single biggest marketing tool you have. Happy customers promote and recommend you. Unhappy customers do the opposite (and are more effective at doing so.)

So, if the metric stops at Customers then you are greatly missing the long-term value. Since a good business is planning for the long term, not just right now, Happy customers I the correct metric.

Remember, you ultimately get what you measure (no more).

[Cthulhu_]

> Happy customers are the single biggest marketing tool you have. Happy customers promote and recommend you. Unhappy customers do the opposite (and are more effective at doing so.)

And yet, there's some irrational counter examples; there's video games that has huge detractors while having huge financial success. Negative reviews on Steam, "4000 hours played". The metrics say they aren't happy with the product... but they still play it, talk about it, may have pulled in friends to play it, and spend money on it.

People can be unhappy about a product but still pay and promote it, counter-intuitively. Of course, the unhappiness is what they say, their behaviour says otherwise so for the sake of the metrics they would be considered happy I suppose?

[virgilp]

When a measure becomes the objective, it ceases to be a good measure.

Even if you could perfectly measure customer happiness (very hard, as you note) - it's relatively easy to make customers happy by giving them more value than what they pay for. Sure, that may cost your business more money than what it makes with said customers, but hey, who cares, "profit" was not the metric...

(and as you note, if you make "profit" the metric, that has its own set of challenges - e.g. the optimization towards short-term profit in detriment of the long-term sanity, which is what we observe in a lot of corporations).

[bruce511]

>> When a measure becomes the objective, it ceases to be a good measure.

Yes and no in this case. Yes, you can naked customers happier with more value, more overhead (ie more support staff and do on.)

Yes, in the short term this might reduce profit. If you go too far down this road you might go bankrupt. No measure works if you dont use the "can we afford it" metric.

But nothing turbo-charges profits (in the short, and more importantly, long term) than happy customers. Ultimately they pay more, theny pay more often, they encourage others to pay.

If you optimize for happy customers, and stay solvent, you have the foundation for a solid long-term business.

I will add that starting with Happy Users (who get stuff for free) and turning them into Happy Customers later is really really hard. Simply giving the thing away (or charging so little it amounts to the same thing) is not what I'm suggesting. You can start with a lower price, yes, but regular price hikes are part of yhe process until uou find your natural price level.

[dfabulich]

I recommend measuring job satisfaction instead of developer productivity. It's the "least bad" proxy metric I know of. https://redfin.engineering/measure-job-satisfaction-instead-...

[musicale]

The interesting corollary to this approach seems to be that productivity barriers are largely external.

A potential riske seems to be feedback systems where job satisfaction is determined by high or low pay.

[eacapeisfutuile]

As already mentioned, people measure value return by revenue gain. It is irrelevant to attribute it to some construct like a line of code.

[nemomarx]

profit generated I think is the high level one, and then you want to dig from there into how much the software development contributed to this.

[nomel]

That's very tricky thing to quantify, especially with "unsung heroes". If my work is in preventing problems, the guy that fixes problems will be seen as the one that contributes more to profit, since impact is directly observed/measured.

This is something that one of the orgs I worked for eventually realized. The people f'ing up, and then fixing their mistakes, were the ones getting promotions/bonuses/raises, because they were the ones interacting with all the execs.

[foobiekr]

Revenue per employee $ spent.