oicr-gsi / robust-paper

Ten Simple Rules for Making Research Software More Robust. Manuscript is published at PLoS Computational Biology. Feedback is welcome!
https://doi.org/10.1371/journal.pcbi.1005412
MIT License
12 stars 0 forks source link

Clarify advice on reusing external programs #31

Closed gvwilson closed 7 years ago

gvwilson commented 7 years ago

Reviewer 1 thinks it's not clear what we're recommending in point 4 about using external programs: are we in favor or not?

morgantaschuk commented 7 years ago

Reuse software

At first I assumed this section was about reusing software libraries, but it transpired to be about reusing executable programs.

This seems an odd guideline. While it's certainly convenient to launch a program using commands like 'system' in perl, it's mostly better to use a library (or service). In fact the authors agree with this in 5, in which case why are we recommending them do this here?

The advice seems a bit confused in general. It's not really clear if the authors are saying if it's a good idea or bad idea to call external programs.

I think general advice to 'take care when calling external programs' may be more appropriate.

built utility / package manager. As noted above the presentation in combo with 4 is confusing. Generally a package manager is used when an external library, module or package is re-used. But as noted there is generally no advice on reusing these artefacts, as 4 is about running programs.

I re-worked the "Reuse software" section to encompass both software libraries and executables, and to tie it in better to the build tools/package manager rule next. I removed the third rule (launch with native functions) since it didn't add much, and substituted a new one: make sure reused software is robust.

morgantaschuk commented 7 years ago

I noticed that reviewer 1 also said

What about software that calls external services?

Which for me was like a "oh shit, that's right" moment. I re-worked reuse software to incorporate mentions of web services.