Tales from the underfunded cousin of DevOps, while trying to get research done.

Yesterday, a tweet by Pauline Bramby added some more fuel to a longer running debate about scientific software development. A number of bioinformaticians I'm following on twitter were arguing about this in their blogs and on twitter. I guess it started off with C. Titus Brown's blog post about single use software. Daniel S. Katz responded with a blog post of his own, and Mick Watson also chimed in. Before we continue, go read these posts, they're all food for thought.

I left a dissenting comment on Titus' post, mainly in a disagreement on some licensing details, and then went on to complain about the high bar Mick was setting for publication from a background of publications that weren't focused on software. Arguably, Mick elegantly excludes those specifically somewhere in his introduction, so I can actually agree with more of his points for software-centric papers. My replies were getting kind of long, and so I decided that it was time to write a proper blog post about this myself.

Then, in reply to Pauline's question on Twitter prompted Titus to muse about soft ware as a primary product of science. The comments have some interesting takes on how we're valuating scientific output in the first place. Daniel came up with a nice post on what a primary product of scientific research could be defined as in the first place. Konrad Hinsen wrote a great comment on Titus' post, and then elaborated in a dedicated blog post. Again, please go read all of these before continuing any further.

A lot of interesting and valuable material in all these blog posts, don't you think? Rather than reiterating all of what was said about software being like telescopes, software being communication and all the other interesting points in that debate, I want to focus on a new tangent. Software development in science is often compared to conductiong experimental work, and because most people argue that experimental work is a means to an end, that is not a primary product of science. So, by analogy, neither should software development be. The actual scientific contribution is designing the experiment in the first place. Now, the analogy has one slight problem here, and I'm tempted to blame that problem on the pretty shoddy practices around software development in science, people have written about this before. Mainly, people seem to assume that implementing the software is all there is for software development. I humbly disagree. I would argue that the analogy with wet lab work would be that designing experiments is like designing software, and conducting experiments is like implementing software. Now if we follow the general agreement that designing experiments is a valuable intellectual input to the scientific endeavour, by analogy so should designing software. So, the answer the question I asked in the topic of the post "Is software development in science an intellectual contribution?" would be "Yes, parts of it at least".

Of course Titus asked a slightly different question, and I'm happy to agree that taken in isolation, software probably is not a product of science. But taken in isolation, pretty much nothing else is either. Konrad made the same point about papers. But I think we're looking at the wrong thing here. I would argue that a good definition of a primary product of science is "it enables further scientific progress". I think that's what Daniel meant when talking about Nobel prizes, but maybe aiming for Nobel prizes raises the bar too high. Scientific progress is incremental, and a good product of science is one that is a solid stepping stone for the next level of science. Software certainly can be such a stepping stone.


Comments

comments powered by Disqus