4 ms·

A large part of this boils down to being able to estimate how much technical debt you can afford to carry. I haven't seen very much code written by researchers

A large part of this boils down to being able to estimate how much technical debt you can afford to carry. I haven't seen very much code written by researchers (scientists/phd students/postdocs). However, from the little I've seen, the tendency sometimes is to either not be aware of technical debt accumulating, or unintentionally overestimating how much can be afforded. This results in unorganized codebases. The other extreme is software engineers who focus overly on the mechanics and always underestimate how much technical debt they can afford. This results in over architected systems which try to plan for all eventualities. Two useful skills to have as a software engineer are to know when to stop writing code and when it's okay to write messy code. The latter being done with the knowledge of when or even if you'll have to clean it up later.

ams6110 12y ago
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.
- collyw 12y ago
  Science is supposed to be reproducible. Writing a script that runs once on a specific machine is unlikely to achieve that.
  - vendakka 12y ago
    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.
  - leephillips 12y ago
    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.
- vendakka 12y ago
  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.

ams6110 12y ago

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.

collyw 12y ago
Science is supposed to be reproducible. Writing a script that runs once on a specific machine is unlikely to achieve that.
- vendakka 12y ago
  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.
- leephillips 12y ago
  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.
vendakka 12y ago
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.