[p10_user]

The majority of academic labs do not have the resources to offer the high salaries skilled coders demand and can easily get elsewhere.

And academic research often just needs to be “good enough” for that next paper or grant. Investing lots of time and people into code quality isn’t worthwhile unlesss your whole goal of the lab is to provide software as your output (there are a few, like the Wikipathways group). Bht for everyone else, the ROI is too low, better off working on the next grant or manuscript.

[mattkrause]

That’s definitely the perception, though I’m not sure how true it actually is. A battle-tested analysis pipeline or experimental control suite is a huge competitive advantage for a lab.

The catch is that it needs to both evolve and stay solid at the same time: it’s hard to predict what you’re going to want in three years—-or find the time to clean up code from the last three years, especially since many of those folks will have moved on.

[rrishi]

It is an advantage but not crucial for grants/papers etc.

[mattkrause]

I agree that it doesn’t matter a whit for any single grant or paper, but one paper (or grant) rarely makes a career.

My claim is that people systematically underestimate the value of good code to a research program. Good infrastructure lets the lab focus on the scientific questions, rather than the logistics of moving and processing the data, which in turn allows them to publish more, better, and faster. This is true for a lot of things: some labs have fantastically good imaging pipelines, or have worked out how to rapidly train animals for certain behaviors, or can reliably do an assay that often fails in others’ hands, and derive a huge benefit from it. Some are so good that I wouldn’t even consider competing with them in their niche. My argument is that good code can also have returns like that.

As a personal example, my first paper at McGill took about three years to finish. The next took about a year and a half (and just came out). We’re on track to submit at least one—-and maybe as many as three—-papers this year. Some of this is due to practice, but a lot of it is due to the fact that we built reusable components instead of “the script that gives the numbers”