"Research code" is often held up as a paragon of what not to do when writing software. Certainly, the kind of code that often results from trying to solve a research problem can end up being poorly-designed, difficult to debug, etc.

But my question is this: does research code have to be this way? Is it possible to write good research code? Is the only approach to consider the first version a poorly-written prototype to be discarded in favour of the better-designed second version?

Software engineering has all sorts of best practices about how to design and write good code, but I don't usually find this relevant when you don't have a good idea ahead of time what the final system will look like. The final system is likely to be a result of what did or didn't work along the way, and the only way to determine what does or doesn't work is to write the code first. As you find things that don't work, you change what the final system looks like, moving further away from your original design (assuming you had one).

I'd be interested in any personal experience with these issues, as well as any books or other resources anyone can point me to.