Research software code is likely to remain a tangled mess
shape-of-code.coding-guidelines.com
Research software code is likely to remain a tangled mess
1–10 of 171 posts
Re: Research software code is likely to remain a tangled mess
#2I agree the post makes valid points, but is there anything new in that? It had been discussed several times here and on other forums as well. "RSE" is just another made-up position with a very average pay structure -- even this is not new.
However, RSEs (or just general software training) may help research groups establish a structure on how to format code, put some standards in place, and at least have some basic tests. This way, more people can read/modify the code efficiently (more = not necessarily general public, but it at least helps incoming grad students/postdocs to pick up the project easily).
Re: Research software code is likely to remain a tangled mess
#3I don't really agree with the reasons given, even though my conclusions are the same. The main reason why research code becomes a tangled mess is due to the intrinsic nature of research. It is highly iterative work where assumptions keep being broken and reformed depending on what you are testing and working on at any given time. Moreover, you have no idea on advance where your experiments are going to take you, thus giving no opportunity to structure the code in advance so it is easy to change.
To make a concrete example, imagine writing an application where requirements changed unpredictably every day, and where the scope of those changes is unbounded.
The closest to "orderly" I think research code can become would be akin to Enterprise style coding, where literally everything is an interface and all implementation details can be changed in all possible ways. We already know how those codebases tend to end..
Re: Research software code is likely to remain a tangled mess
#4I don't really agree with the reasons given, even though my conclusions are the same. The main reason why research code becomes a tangled mess is due to the intrinsic nature of research. It is highly iterative work where assumptions keep being broken and reformed depending on what you are testing and working on at any given time. Moreover, you have no idea on advance where your experiments are going to take you, thus…
There's only one way to solve this: Simplicity.
Ironically this is also what occams razor would demand from good Science, so you'd have a win win scenario, where you both create good software and good research, because you focus on the simplest most minimal approach that could possibly work.
Re: Research software code is likely to remain a tangled mess
#5I don't really agree with the reasons given, even though my conclusions are the same. The main reason why research code becomes a tangled mess is due to the intrinsic nature of research. It is highly iterative work where assumptions keep being broken and reformed depending on what you are testing and working on at any given time. Moreover, you have no idea on advance where your experiments are going to take you, thus…
There certainly is quite a lot to be said about constant requirements drift. However, this is not something untypical to some of fast-paced product work or, even more closely, r&d effort within the industry.
What then drives the improvement of the code quality is the potential need for continuity and knowledge retention - either in the form of iterative cleaning of the debt or the re-write. This is reliant on the perceived value for the organisation. From this perspective it's more straightforward to get to author's reasons.
Re: Research software code is likely to remain a tangled mess
#6I am actually quite surprised at the figure of 73% research-related code packages not being updated after the publication, was expecting it to be higher.
Re: Research software code is likely to remain a tangled mess
#7I think that incentives play a big role here. Software has near to zero value in academic evaluation and even less its update and maintenance. The only way to make research software survive is to offer packages that other researchers can also use. Maybe.
Re: Research software code is likely to remain a tangled mess
#8Not all research software is a tangled mass. I have extensively worked as a "quant" (before the term was popular) for math, medical, network, media, and physics researchers as my side gig for decades. I'd say about 1/3 of the home brewed research software is constructed with fairly reasonable assumptions, the authors are scientists after all, and I am able to grow their basic setup into a framework they intimately understand and prefer to use. More than once I've found brilliantly engineered software not unlike what I'd find at a pro software development firm.
Re: Research software code is likely to remain a tangled mess
#9I don't really agree with the reasons given, even though my conclusions are the same. The main reason why research code becomes a tangled mess is due to the intrinsic nature of research. It is highly iterative work where assumptions keep being broken and reformed depending on what you are testing and working on at any given time. Moreover, you have no idea on advance where your experiments are going to take you, thus…
Yes, not pointing out the difference between coding some novel technique and a well defined software project, completely misses the reason the code is often not well organized. Suggesting that researchers are bad programmers is just a lazy excuse, somewhat damaging, and by no means the rule. I wrote a large complex framework for my research and the very nature of it causes me to add modules and techniques for parts I didn't know would work. And at times hard forks for when I wanted to try something new, which merging back would be impossible to do cleanly. At times you have a hunch and like a fever dream, change who knows what, but you just have to see something through. There is no waterfall method, kanban and agile makes no sense here and even unit tests are I'll defined.
Re: Research software code is likely to remain a tangled mess
#10I did some research projects, but the problem is that they are a mix of regular projects and experiments.
Things like Nix worked out great, but other stuff I saw is a tangled mess of Java grown over the last 10 years, written by 30 different students that didn't talk or let alone knew each other.