3 ms·
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 p
by falcor84 3y ago
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.
- riffraff 3y agoEven 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.
- PokestarFan 3y agoLook up Goodhart's Law.
- alanbernstein 3y agoWouldn't it be easier to "game" the tool by just not using it?
- gwbas1c 3y ago> 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.
- IanCal 3y agoThen the rails example on the main page is wrong.
- WorldMaker 3y agoPeople 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 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.