4 ms·

Right, that's what I meant by code review in the first paragraph: internal review within the research group. Agreed also that they should use version control a

Right, that's what I meant by code review in the first paragraph: internal review within the research group. Agreed also that they should use version control and other standard practices, etc.

lol768 7y ago
> Right, that's what I meant by code review in the first paragraph: internal review within the research group. Ah, I took it as code review during the peer review process (i.e. from reviewers). Unsure how realistic this would be.
- allenofthehills 7y ago
  > Code review during the peer review process Unfortunately, this would make the already laborious process of peer review even longer and require more work. Given the reality of academia today (publish vs perish), not to mention the added work of preparing even well structured, version controlled code (which is not, in my experience common) for publishing, most researchers would not opt-in (or support) something which would make publishing more difficult.
  - DavidSJ 7y ago
    Maybe this sounds harsh, but: Who cares? If researchers are producing crap to get published, why should we mind if they stop producing that crap when journals raise the standards of publication?
- DavidSJ 7y ago
  That’s what I was referring to in my second paragraph. :)
benmaraschino 7y ago
The way many clinical research groups are structured (unfortunately) precludes code review, and to some extent, version control. Often for projects like the one referenced in the OP you'll have just one statistical programmer working with a PhD-level biostatistician in addition to the MD investigators. The biostatistician guides the programmer through the statistical methods to use and steers the overall study design, but otherwise they never see the underlying code. There are some exceptions, but in many cases, the programmer ends up the only person seeing the code. A lot of this has to do with how funding is structured—grants are written assuming one FTE programmer, and something like 0.05 FTE for the biostatistician. It's hard to convince funding agencies that you need more than one FTE programmer in many cases; on top of that, farming out the biostatistican's time in small chunks like that splits their attention between dozens of projects, which precludes them engaging with any one of those projects in depth. So, there's literally nobody else on these projects who could conduct a code review. This also sort of provides a disincentive towards using VCS even though it's so obviously a good idea if you're the only person contributing code—I've talked with programmers about this before and the response is "why bother?" unfortunately.

Right, that's what I meant by code review in the first paragraph: internal review within the research group. Agreed also that they should use version control and other standard practices, etc.

lol768 7y ago

> Right, that's what I meant by code review in the first paragraph: internal review within the research group. Ah, I took it as code review during the peer review process (i.e. from reviewers). Unsure how realistic this would be.

allenofthehills 7y ago
> Code review during the peer review process Unfortunately, this would make the already laborious process of peer review even longer and require more work. Given the reality of academia today (publish vs perish), not to mention the added work of preparing even well structured, version controlled code (which is not, in my experience common) for publishing, most researchers would not opt-in (or support) something which would make publishing more difficult.
- DavidSJ 7y ago
  Maybe this sounds harsh, but: Who cares? If researchers are producing crap to get published, why should we mind if they stop producing that crap when journals raise the standards of publication?
DavidSJ 7y ago
That’s what I was referring to in my second paragraph. :)

benmaraschino 7y ago

The way many clinical research groups are structured (unfortunately) precludes code review, and to some extent, version control. Often for projects like the one referenced in the OP you'll have just one statistical programmer working with a PhD-level biostatistician in addition to the MD investigators. The biostatistician guides the programmer through the statistical methods to use and steers the overall study design, but otherwise they never see the underlying code. There are some exceptions, but in many cases, the programmer ends up the only person seeing the code. A lot of this has to do with how funding is structured—grants are written assuming one FTE programmer, and something like 0.05 FTE for the biostatistician. It's hard to convince funding agencies that you need more than one FTE programmer in many cases; on top of that, farming out the biostatistican's time in small chunks like that splits their attention between dozens of projects, which precludes them engaging with any one of those projects in depth. So, there's literally nobody else on these projects who could conduct a code review. This also sort of provides a disincentive towards using VCS even though it's so obviously a good idea if you're the only person contributing code—I've talked with programmers about this before and the response is "why bother?" unfortunately.