The code itself is always usually a mess: no readme, no license, random binaries, and a 'pipeline' which is simply a bunch of perl and python scripts cobbler together from snippets found on the web.
People publish, then move onto the next project. There is no maintenance.
Excuse me. Is this your actual experience or the meme that everybody is simply repeating?
In the admittedly few papers I have published, the reviewers’ feedback has been a net positive I wouldn’t be without.
Also, the general focus on code in science here on HN is so incredibly myopic and narrow minded. Code for research are not high-profile software projects. They are a piece in the toolbox used to solve a problem. Some grow to become larger projects, some fulfill their purpose and stay fixed in time.
I agree with you that this is research and there's no reason for it to be pretty. The fact that it's unsightly and brittle makes a lot of people reticent about sharing it online since it could reflect on the quality of their non prototype code. Maintenance is a large burden and once the original goal of the paper has been proved, there's little benefit to the researcher to keep the code around, so I understand why they might say let's not release it at all.
A recent example of this was I was building a gesture classifier using an accelerometer to generate data. I decided do use an svm as based on what I had read, it would be the simplest to port to the microcontroller I was using. I was getting decent performance but needed to extract better features. I found several papers talking about the topic with some novel ideas and their impressive results. While it was nice to know that accuracy could get that high, none of the papers explained how the features they extracted were made. It was usually a one or two sentence line about using both time and frequency domain data.