calcifer
Hey Cal, are you the maintainer of this tool we use in our build?
(ooh, maybe they're asking about adding a new feature!) Yeah, what's up?
The last commit was 3 years agoβ¦
Seems right, yeah
Shouldn't it be updated?
If there's a problem to solve or an improvement, then of course. What do you need?
I can't think of anything, it just seems kind of old
When you write careful code, it doesn't rot as quicklyβ¦
Breathe, Cal. Breathe.
Vertigo #$FF
@calcifer are you sure all of the copyright notices are up to date? π
It burns me up when people conflate a dead project with a live one which has no further evolutionary pressures.
Christian Horn
@calcifer There is now apparently generation 'I know apps on mobiles, and project that to all software', which has concluded everything without updates for 6 months is broken.
I guess these folks get a heart attack when being told about TeX. https://en.wikipedia.org/wiki/TeX#Development
calcifer
@mdhughes nah, this is solveable by educating the newer/younger folks that "time since commit" isn't as strong an indicator of utility as they assume, especially for internal projects
I want to fix the perception problem, not reinforce it. One of the perks of having seniority and authority in an org is you can actually improve culture
Digital Mark Ξ» π πΉ πΎ π₯
@calcifer Write a bot that randomly touches files every few weeks with non-breaking changes.
calcifer
@daniel in my experience, "hey it hasn't been changed in a while" doesn't really carry much signal
Bitrot is, of course, a real thing. But it's so variable that code age doesn't really tell you if it's a problem. Recent code is likely less tested, but not always. Older code could be abandoned or broken in subtle ways, but not always.
Code that's old but lots of people are actively using tends to be a really good thing (but, again, not always), because it means it's been tested 8 ways from Sunday and no one is having reportable problems. Problem is people think "old = abandoned and abandoned means bugs"; but that has so many exceptions that it's not nearly as useful as people think.
Daniel (CactiChameleon9)
@calcifer Is it bad to have a bias against unchanged code? (especially with complex projects)
Probably need to think through that kinda stuff more
Aearo, a SeaWyrm
"I want to fix the perception problem, not reinforce it" is a really important stance for lots of things, and I wish more people would take it.
ollibaba
@calcifer TBH, for external tools I find the date of last commit interesting, because it gives a hint whether the maintainer still cares about it. A recent commit somewhat indicates that "someone might be available to help me if I _do_ find a bug".
It doesn't have to be a recent commit, though; activity on the bug tracker (by a maintainer) is just as well.
But yeah, for in-house software these heuristics don't work at all, IMO.
Chirp! is a social network. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All Chirp! content and data are available under the Creative Commons Attribution 3.0 license.