The advice "choose what's oldest because it's most likely to work" has limited mileage. Here, technology can refer to tools that solve generic problems in math, computation, or software development, or could refer to tools that solve more domain-specific problems. In either case, I think the "software age" criterion is problematic on its own.
In my field there's BLAST, which has been around since the early 90s and has thousands upon thousands of citations. But it's also still actively developed, and has a huge user base. For each "BLAST" there are dozens and dozens of washed-up has beens, tools that solve a particular problem but are riddled with poor documentation and half-arsed software engineering practices, tools that never really got much traction and never had enough support to reach maturity. Relying on age as the primary criterion for evaluation would lead a budding RSE into some troubled waters in my field (and I suspect many other scientific fields).
I'd say the age of the code/project is a great key indicator, but can be useless (or worse) without a good understanding of how actively the code is developed, how widely the code is used, and (when possible) the track record of the scientist for creating useful and usable software.
My impression is that these observations from the bioinformatics/genomics fields generalize pretty well to software more widely. Should we update the materials to reflect this?
The advice "choose what's oldest because it's most likely to work" has limited mileage. Here, technology can refer to tools that solve generic problems in math, computation, or software development, or could refer to tools that solve more domain-specific problems. In either case, I think the "software age" criterion is problematic on its own.
In my field there's BLAST, which has been around since the early 90s and has thousands upon thousands of citations. But it's also still actively developed, and has a huge user base. For each "BLAST" there are dozens and dozens of washed-up has beens, tools that solve a particular problem but are riddled with poor documentation and half-arsed software engineering practices, tools that never really got much traction and never had enough support to reach maturity. Relying on age as the primary criterion for evaluation would lead a budding RSE into some troubled waters in my field (and I suspect many other scientific fields).
I'd say the age of the code/project is a great key indicator, but can be useless (or worse) without a good understanding of how actively the code is developed, how widely the code is used, and (when possible) the track record of the scientist for creating useful and usable software.
My impression is that these observations from the bioinformatics/genomics fields generalize pretty well to software more widely. Should we update the materials to reflect this?