12 ms·
You imply that you're still going to understand your code one year later. While this is a favorite fantasy of all programmers, it's usually false. Also, if you'
by majewsky 9y ago
You imply that you're still going to understand your code one year later. While this is a favorite fantasy of all programmers, it's usually false. Also, if you're in a team, the person running into the bug is likely not you, so it's foreign code for them anyway.
- jsmeaton 9y agoI was being brief because I was leaving work so I’ll expand a bit. An unmaintained library is usually more difficult to fix because fixes are no longer committed back or released. At that point you can choose to vendor and maintain your own copy, or replace it with something else. And at either of those points you’re no longer in context. My point wasn’t really geared at debugging a piece of code. A library, my own, or a coworkers are roughly comparable. The cost to fix is a lot higher in a library though. It’s not a universal rule, despite the way I originally phrased it.
- V-2 9y agoI think there is also certain negative selection bias in the sense that people are more likely to stop maintaining libraries that were badly designed / problematic to begin with. That's why I tend to be more sceptical than average when it comes to "orphaned" projects.