Research code is production code and should be treated as such. It doesn't matter if requirements change quickly, you still need to treat it like it's production code... you document, test, and deploy it. And you should include the ability to adapt the code to flexible requirements in your initial design.

Just because you may only use the program once doesn't mean that you can neglect good software engineering practices.

I run into bad code all of the time (some of it mine!) in our research, and it's very frustrating.

If your research code is a big ball of mud then all it's results are meaningless. And all your research should be rejected by any competent journal. Sadly, journals tend to ignore such huge issues.

But, hey it's not like reproduceable results are important in science or anything.

The more computational journals are keeping track of this. I've had a manuscript returned for revision because I didn't have enough unit testing in the code. Wet-lab journals, on the other hand, probably let a lot of stuff go on the computation and statistics than they should.

> requirements can change quickly and drastically

the implication that this threat is not present for production code is completely ridiculous.

Any significant dataset should be wrapped with an object. Especially so if multiple scientists/programmers are pulling data from the dataset.

Ever tried multiple algorithm variants? Wrapping an algorithm in an object and then passing it to the data provisioning code means you can be 100% sure that the only thing that has changed in your code is the algorithm.