Something I don't get is why universities don't to a better job of having professional statisticians and programmers on staff for the explicit purpose of providing support to researchers.
I guess grad students are cheaper and "good enough."
I guess grad students are cheaper and "good enough."
- Research is an iterative creative process. The creation of the code is an organic process of discovery and not a separate stage from writing it's specification.
- The jobs are too small to split up. This is the same in industry. Try to split up a small task (1 person, 2 weeks) over a small team of specialists (Analyst, programmer, DB specialist, dev-ops, tester and now you need a project manager, ...) and suddenly it becomes way, way larger than it should be.
- Most production programmers realy dislike working in research environments. The objectives and nature of research code is very different from what turns-on and drives professional programmers, so you wouldn't have 'the best professional programmers' working there anyway.
Being able to code well enough to do your own experiments is part of the researcher's skill-set. Grad students should become 'good enough' at it. >
Let's not kidd ourselves. Independent academic research is a constant struggle for funds. Nobody is going to pay for a magnitude increase in the costs. If you are looking to up the quality, best look into how to get academic research out of the ridiculous quantified output metrics conundrum.
I've used the service before and can recommend it.
Don't know anything comparable for programming at UT, though I can say that UT's computational science (different from computer science) program has some good classes on software engineering practice aimed at practicing research scientists and engineers.
As for programmers, it's not just a matter of cost. Most scientists don't understand software engineering, but most software engineers don't understand science or math. Also, programmers who belong to their own organizational structure can't keep up with requirements that could change from one hour to the next. Despite "agile," realistically most software development is comfortable with timelines of months or years.
Don't get me wrong, I'm an R&D scientist at an industrial business that makes commercial software. The programmers are brilliant, and the software they make is amazing. But I have no choice but to be self sufficient for my own software needs in R&D. It's two different worlds.
Moreover what I propose is that every researcher have a programmer available to consult with, who would perhaps write small amounts of code (perhaps make sure the code builds before it's published?) I don't suggest that researchers not write code, I think they should write code. But I think an expert in writing code should be available to help keep the standard of code high.
This stuff evolves over multiple iterations. Many of my programs never run more than once. Testing them requires being connected to the equipment if any kind of closed-loop control is involved.
I work in an R&D setting in industry. If something I make threatens to become a product, the thing I hand over to the software team is a proof of concept, that could include a hardware design and working code.
I wasn't making much above minimum wage working as a programmer at a university. People with computer science degrees don't tend to take such jobs, when they've got half the west coast waving 6-figure job offers at them.
Again, it comes down to the user and the customer not being the same person. The person reading the research paper would sure like it to have been written (or at least debugged) by an expert programmer, but it would be some department who would have to have paid for such a programmer. Departments don't have budget for that, and their currency is publication, not correctness proofs.
(I assume departments would have to pay, because we paid for all other IT services. We even had to pay the university for network access. It's not like the library, which is always free to everyone on campus.)
Complete lack of incentives to do so.
Academics are, by design, inbred. They care only about what other academics think. And few of them care about code quality. The attitude is slowly, slowly changing, but I think even now in most disciplines it is not the norm to share your code when you publish papers, and it is not surprising for an author to refuse to provide you the code when you email them.
Until journals require academics to submit any code used for simulations/analysis, things won't change.
In any case: To answer your question - there are always some programmers on staff for large scale research projects. I doubt they're judged by code quality, though.
Compelling researchers to release their source code would be the next step, but they'll fight you tooth and nail on that one. Many researchers are in very competitive fields and think that releasing their source code might give some other team a boost. I think this attitude is contrary to the interests of scientific progress, but because it's a matter people have such strong personal stakes in, it could prove a hard fight.
Chemistry departments often have glassblowing technicians. Perhaps this would be comparable.
I guess I wasn't clear enough to connect all the dots. These kinds of policies are made by academics. The people with the authority to mandate this are themselves academics who got promoted. The reason the universities will not do it is because of the nature of the people in charge.
Academics don't work for these people. They are these people.
Pretty much the same story with grant approvers and journal editors. Mostly from academia.
The argument to do it is to improve the quality of the research output. But guess who evaluated the quality of the research?
It doesn't matter that you and I know this is an incredibly unreliable way to do research. As long as academics can continue to publish their papers with crappy software practices, they will do so.
As I said, there is a lack of incentive to do this. Who will benefit? Probably over half of researchers do not want someone to find flaws in their methodology. In my discipline, it was common to leave out inconvenient details from a paper. Common enough to the point of psychosis: The researchers convinc themselves that the flaw is not a problem, so it's not even a question of integrity any more. It's poor incentives leading to a few generations of researchers who are trained to be blind.
That is generally referred to as "research software engineers/groups" and are unfortunately currently fairly rare in academia, but are becoming more common. RSECon is dedicated to this topic, and hosts a list of research software groups [1]
[1]: https://rse.ac.uk/community/research-software-groups-rsgs/
All I could do to save face was point her to some resources, because if I said what I really thought, it would be in a trash can set on fire.
Or to put it another way: maybe they don't do it, because if they did, it would stop the requisite amount of papers being published.