| I used to be a software lead in a research organization. I have a LOT of opinions on the subject but I'll give you just a few points. - I've seen many cases where researchers refused to share their code because they knew it wasn't up to any reasonable standard. This is a red flag. If they are embarrassed by their code, I tend to discount their alleged results entirely. - Even in research, people should be required by the organization to follow some kind of process. Use version control (like git or even svn. This basic step is still not universal), put in pull requests, get code reviewed from someone else. - For that purpose, every research organization should have someone on staff who can do a competent review. They do not need to specialize in the researcher's field. They just need to know a code smell when they see it. - Every researcher I have known will resist this strenuously. That is a sign of how much they need it. - When publishing research results, code and data should always be required. Otherwise, the results cannot be judged. (A lot of people like it that way. They should not be accommodated). I could go on but I'll be nice and stop here. |
Your researcher got a result. Great. What is their objective evidence that the result is real rather than an artifact of a bug in their code? If the code is garbage, you can't trust the result, no matter how much of a breakthrough the result would be if true.
That doesn't mean that the code needs to be production-ready. It does mean that the code needs to be clean enough to be trustworthy. (Tests can be included in this evaluation.)
If the code's going to be product-ized... maybe ask the researcher which parts of the code they think are the most troublesome. Start by re-writing those pieces, from scratch, with production levels of rigor. Then, as other parts prove troublesome, rewrite those too. Don't band-aid them, rewrite them. Keep the interfaces, unless the interface itself is part of the problem.