I'm highly skeptical about the tech debt measurement algorithm this article purports to be developing.

Google researchers recently published a paper on their attempts to measure technical debt.

They tested 117 metrics that were proposed as potential indicators.

Regressions were used to test each metric to see whether it could predict an engineer’s perceptions of technical debt.

No single metric or combination of metrics were found to be valid indicators.

Researchers who specialize in this field largely disagree with this. Here's a round-up: https://getdx.com/blog/measuring-developer-activity/

I'm one of the co-authors of the study. I think your sentiment is valid but what you describe is true for most fields of research: conflicts of interest can be a problem.

I can attest to the fact that the researchers behind this study have extensive backgrounds in academic research and hold themselves to high standards. If nothing else, not doing so risks putting individual reputations on the line.

https://queue.acm.org/detail.cfm?id=3595878

You can't measure developer productivity objectively, assuming you're referring to metrics like lines of code, number of pull requests, or velocity points which are infamous. There's broad agreement on this both within the research community as well as practitioners at leading tech companies.

Here are some examples: https://newsletter.pragmaticengineer.com/p/measuring-develop...

"... and what distinguishes 'good devex' from 'bad devex'"

Yes to this. This is an ongoing effort - we have two previous journal papers that touch on this which may be of interest to you:

- https://getdx.com/research/devex-what-actually-drives-produc...

- https://getdx.com/research/conceptual-framework-for-develope...

It's fairly well-established in research (and in practice) that there is no objective measure of developer productivity. Metrics like lines of code, number of pull requests, velocity points are incredibly poor proxies.

If you read the introduction of the paper, you'll see that the aim of this paper is to give managers and developers concrete data to use to help get buy-in on investing in developer experience from business leaders.

https://queue.acm.org/detail.cfm?id=3639443

Comments URL: https://news.ycombinator.com/item?id=39016635

Points: 2

# Comments: 0

From what I can tell, this approach involves the vendor creating and managing a customer’s software instance, but doing so in a single-tenant model on the customer’s preferred cloud provider.

I’m curious to know how this works. Does the vendor get access the customer’s AWS/Azure/GC account and then create the resources to run the software there? Or does the vendor deploy the software in their own cloud accounts in the region/provider preferred by the customer, and then somehow keep the instance confined to being accessed within the customer’s network?

Example: https://document360.com/private-hosting/

Comments URL: https://news.ycombinator.com/item?id=34466840

Points: 1

# Comments: 4

Comments URL: https://news.ycombinator.com/item?id=34368395

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=34275009

Points: 2

# Comments: 0

There finally seems to be some level of consensus that output metrics like lines of code, # of PRs, and commits, are an ineffective approach.

Lean metrics like cycle time and lead time can be a helpful high-level diagnostic, but they're far from an indicator of effectiveness or productivity.

A new approach being adopted by many organizations is to focus on the actual experiences of developers... the things that slow them down or frustrate them... and turn these into measurements that guide improvement. I'm the founder of getdx.com where we're publishing research on this: http://paper.getdx.com