It's not only a problem of bad software, it's a problem of lack of testing, lack of proper development management (two factors of bad software, indeed), but mainly a problem of poor or lacking documentation. Not code comments, but actual documentation that allow other people to use the program. This leads to improper usage, errors that cannot be solved and are not reported and/or noticed by whoever is running the software.
Absolutely. But I think that testing is still the bigger problem; a lot of scientific software is used in conjunction with other scientific software, and the interfaces themselves are also usually undefined and untested. So something as simple as IT upgrading a package to fix a bug or add a feature might break a lab's workflow in ways that are difficult to detect. It's easy to mess this kind of software up by creating code that produces incorrect results despite appearing OK by the field's dominant scoring criteria.
Also publish and forget... that's just the natural fallout of the way research is conducted and funded. I've written scientific software that I don't feel much personal obligation to maintain or update. It's challenging work which has greatly reduced payoff (to the powers that be) after it has been tallied on the scoreboard. Also, most positions in scientific labs are on a clock; not exactly an environment that fosters long-term stewardship.
I'd love to see science funding agencies spend a couple million to fund reasonably sized groups of 5-10 programmers/scientists to produce code over ~3 year funding cycles. Just to make sure that signals don't get crossed, these groups should be told not to spend a single minute of their time on publishing to journals. Dissemination is limited to short talks and training workshops. Continued funding would also focus more heavily on user surveys than third-party citations.
I agree with everything you mentioned. I have tried to establish some testing procedures in the labs I have been in the past, where even backing up data was a myth, with zero success. With the requirement to compile code in four different OSs, testing and some automated procedure was the key, but not one person came on board.
Now moving to a diagnostic setting, and working by myself, testing and documentation have been the main goals to me. And now, every single piece of third-party software has to be exhaustively validated in every aspect before being put into production mode.
"I'd love to see science funding agencies spend a couple million to fund reasonably sized groups of 5-10 programmers/scientists to produce code over ~3 year funding cycles. Just to make sure that signals don't get crossed, these groups should be told not to spend a single minute of their time on publishing to journals. Dissemination is limited to short talks and training workshops. Continued funding would also focus more heavily on user surveys than third-party citations."
On the side of software/funding, your ideas are spot on. I think it is about time to have professional and steady funding to keep software working and available. I haven't published app notes or the like in the past, most of the software I worked on were never published, but I see important applications where the code is not open source, there's no testing and no updates for years. We need to move from the on-the-clock science to some model that would allow scientific software to be properly maintained.
Maybe if we treated scientific software like we treat "regular IT", might be the key.
Not to mention the publish-and-forget.