Hacker News Reader

Comment by d-k-bo | Hacker News Reader

I think it only counts direct dependencies.

So that means that the way to game this would be to create a wrapper project (e.g. called "external_deps") for all of my dependencies, and then have my actual project depend on that one. So I'm externalizing all of my tech debt onto external_deps and as long as I never make a new release of that, my main project will always be 0 libyears old.

Even if you could, why would you? It'd be the same to, say, fork a projectX to myprojectX and say you're at the latest version.

You are the one that has an advantage to know you're behind, not someone else.

Look up Goodhart's Law.

Wouldn't it be easier to "game" the tool by just not using it?

> So that means that the way to game this would be to create a wrapper project (e.g. called "external_deps") for all of my dependencies, and then have my actual project depend on that one

No, you can't resort to chicanery to manipulate your metric.

In this case, the libraries you want to use become transitive dependencies, but if your code uses those transitive dependencies, then your project still depends on them.

Then the rails example on the main page is wrong.

People already do that with vendorizing, too. It was noted the other week on HN of someone "collateralizing" their tech debt by vendorizing a dependency to remove CVE/deprecation/obsolescence warnings for a Rust dependency with no update path: https://news.ycombinator.com/item?id=39827645

A metric like this can't keep you honest (just about no matter how you design it, people will find loopholes), but it can help honest people document their needs.

Reply on news.ycombinator.com