Hacker News new | ask | show | jobs
by api 1547 days ago
This is even a problem in software. People ignore projects that have not had GitHub commits recently, as if code (which is math) somehow becomes less valid over time.

Yes a "dead" project can be problematic if you need it maintained and don't have the time to DIY, but sometimes something reaches a level of stability where it does not need to be constantly fixed. Something with a lot of users and few commits might be a positive indicator since it might mean there aren't a lot of bugs.

2 comments

A lot of software has dependencies that will have changed over time. Likewise a lot of software fails to pin down exact versions of said dependencies. That makes code that hasn't been committed to for a few years relatively likely to be broken.

Older C or C++ projects may be "standalone", but when built with the latest GCC or clang produce lots of warning messages and may be miscompiled courtesy of programmer vs optimiser. Older python programs may refuse to run under python3.

So while code does not rot, the GitHub project is unlikely to contain all the code for the project, and those external dependencies changing has much the same effect as rotting.

A still running CI would be a better indicator that the project works, but failing that, recent commits are the same signal.

This is the one thing I hate about software. I don't want to have to re-learn how to use a re-invented wheel every couple of years. I just want to use robust, time-tested tools to solve problems, like in virtually every other field of engineering.
I'm not under the impression that e.g. pressure vessel design or bridge building follows the same safety rules now as it did 40 or 80 years ago. You might learn the same basics in university, but in practice the rules and tools are also evolving all the time.

So the "robust, time-tested tools to solve problems" also become obsolete in other fields of engineering. I think this is not unlike "compiler warns about more unsafe practices nowadays".

The velocity (aka churn) is a lot higher in software though, for questionable benefit.
Yeah, but people still do it in, say, Rust, where that's not the case.
The opposite could also be true. Now that I have experience working on vulnerabilities for enterprise software, I've learned there are constantly updates for mitigating software vulnerabilities that didn't exist a month or even week ago. An old java project may still use a version log4j with that major vulnerability. This may not be a big deal depending on the software, but it is a valid reason to be wary of stale code in some cases.