Hacker News Reader

Comment by djaque | Hacker News Reader

The point is that as a scientist your code is a tool to get the job done and not the product. I can't spend 48 hours writing unit tests for my library (even though I want to) if it's not going to give me results. It's literally not my job and is not an efficient use of my time

View on HN

If the code you base your work on is horrible it definitely makes me question your results. That's why it's called the reproducibility crisis.

Writing some tests, using a linter, commenting your code, and learning about best programming practices doesn't take long and pays off - even for yourself when writing the code or you need to touch the code again. "48 hours writing unit tests" is a ridiculous comparison.

No, the reproducibility crisis is that when 10 people write the same library you all get different results.

This is just complaining that science is too hard because you can't be bother to replicate an experiment.

This is the same as any other argument against testing. Unless you are actually selling a library, code is not the product. Customers are buying results, not your code base. Yet, we've discovered the importance of testing to make sure customers get the right results without issues.

If you want your results to be usable by others, the quality of the code matters. If all you care is publishing a paper, then I guess sure it doesn't matter if anyone else can build off your work.

But the results are usable by others, in most fields of science the code is not part of these results and is not needed to enjoy, use and build upon the research results.

The only case where the code would be used (which is a valid reason why it should be available somehow) is to assert that your particular results are flawed or fraudulent; otherwise the quality of the code (or its availability, or even existence - perhaps you could have had a bunch of people do all of it on paper without any code) is simply irrelevant if you want your results to be usable by others.

> The only case where the code would be used (which is a valid reason why it should be available somehow) is to assert that your particular results are flawed or fraudulent;

Not true. Code is often used and reused to churn out a lot more results than the initial paper. A flaw in the code doesn't just show one paper/result as problematic. It can show a large chunk of a researcher's work in his area of expertise to be problematic.

> The point is that as a scientist your code is a tool to get the job done and not the product.

Everything you say is as true for experimental equipment and mathematical tools. Physicists are fantastic at mathematics, yet are one of the most anti-math people I know - in the sense of "Mathematics is just a tool to get results that explain nature! Doing mathematics for its own sake is a waste of time!"

The equation is not the product - the explanation of physical phenomena is. If the attitude of "I don't need to show how I got this equation" is unacceptable, the same should go for code.

> I can't spend 48 hours writing unit tests for my library

No one is insisting on top quality code, but there has to be an acceptance that code can be flawed and that needs to be tested for.

How do you know it won't give you results? Maybe it will find a bug that would have resulted in an embarrassing retraction.

Maybe it wouldn't find any bugs, but give confidence to and encourage other users and increasing your citations and "impact".

Maybe it will just save you 48h later on when you need to adapt the code.

Software engineering has generally accepted that unit testing is a good practice and well worth the time taken. Why do you think science is different?

> Why do you think science is different?

It's really not, I guess his focus lies on cranking out irreproducible papers.

Reply on news.ycombinator.com