Technical debt is often irrelevant in scientific code. It's one-off code for a specific experiment. In many cases, once the paper is published nobody will ever run the code again. That's not always true, but it often is.
Meaningful reproducibility would mean writing your own code and performing your own experiment in a different lab with different people to see if the results hold up. Running the same code more times on the same machine, or repeating a measurement in the same lab with the same people isn't what we mean by "reproducing" a result.
Exactly. This is the kind of technical debt I'm referring to when it comes to code written for science. Not something that can be used as a platform/library, but also not code having references to a single config file hard-coded in 5 places.
That is very true. I re-read my comment and realized it might come across as being critical of folks in academia not caring about technical debt, which was not the intention.
Technical debt in these scenarios is usually limited to a single paper cycle (or maybe 2). This is avoided with simple practices such as planning out your code with comments before writing it, not copy-pasting code into 3 or 4 places, etc. There isn't much overhead, but it saves a fair bit of time debugging issues caused by human error. It also ensures you write as little code as necessary for the problem at hand.
I completely agree that when it's just a single paper, there is not much need to ensure you have an elegant library which can be re-used.
