I think the first two are probably the right kinds of problems. Even in normal software engineering, you want to try out PoC's to prove that they are what your customer wants, and that things generally work the way you think they should.
Code quality is another problem entirely. I agree code quality can get out of control as soon as the PoC is promoted to something resembling "production."
My suggestions are:
- First, if you get frustrated at researchers for code quality, let them calmly know why you are upset. If they are being inefficient, many would love to hear tips to keep it from happening. Let them know when the things they are doing might affect large groups of people.
- Don't try to write tests for everything. This just slows you down, getting away from the good things above. Write tests for things that are frequently broken, and absolutely required to work, such as core functionality. If something gets broken 2 or 3 times, you should definitely have a test.
- Make your tests as high level as possible. Compute power is cheap, and despite what you might hear from the TDD/unit testing crowd, your tests don't need to run in 2 seconds to be useful. I like to have tests that emulate users, because as you change the logic of how you're doing things, you still have tests to back you up.
- Add lots of additional logging. This helps document the code (since the messages should be useful and say what is going on), and provides great info for debugging issues after they've already occurred. I've been saved by good logging more times than I can remember, especially on different OS/environments that aren't the test environment.
- Don't worry too much about edge cases. Just print a log line or crash out if it's something ridiculous you've gotten yourself into, which is a lot more friendly than figuring out some horrendous bug mired in retry logic that has masked the original issue.
- Insist on version control, but not code reviews. Code reviews can really slow you down. Instead, fix problems after they come up. You haven't shipped, right?
- Run the build and tests in a simple CI loop that runs overnight. Don't worry about testing each commit, just know if it works or doesn't work. Fix the problems.
These last two are related:
- Feel free to just start over. Delete huge amounts of code, and try a different approach.
- If you have gone past the point of no return (you don't want to start over), then start production-izing the code. Again, aim at the problems to start, not some coverage metric. Look over all the code and reduce redundancy. It's a lot easier to review code once it's all there, rather than bit by bit.