So what if there are bugs, isn't what matters that the answer is correct? This is done, at least in my organization, as follows:
1) with a test problem. you can run a calculation that is easily solved analyitically and then compare results. You can also challenge yourself a little more by running a problem with ready experimental results for, and then again, comparing results. Only after this first step is done (many, many, many times)does confidence in the code build up and it can begin to be used in new areas. This is called qualification, verification, or validation.
2) When attacking problems not previously solved (which, after all, is the reason for writing the code), the scientist/engineer/end-user must have an expectation of what the results will be like. They may not know values, but they should expect what has changed since the last model they ran (i.e., "if I increase temperature by 10 degrees in my model, then this should happen...").
3) While this may not be possible in all fields, either an experiment, or manufactured product should be tested to ensure that you got out what you predicted with your code. Engineering organizations can do this. Climatologists probably can't, I'd imagine.
While I don't care about the debate of opening up the source code, I take issue with the fact that a comp sci guy looked at some scientist/engineer's code and said 'omg bugs!' Sure, it may not be how the comp sci expert would program, but it doesn't matter in the end (provided qualification is done adequately).
Personally, I don't want to open up my code beyond who is necessary to see it - the code is not the end, its just a means. Its like a Doctor allowing everyone to see his personal diary on patients - its only work to support the diagnosis, and not the diagnosis itself.
