In terms of software regulated as a medical device is it essential for source code to be reviewed by a second party as part of software validation?

We currently have one Software Engineer who writes our code. Nobody else is qualified to read the actual code and look for errors. Our validation strategy mostly involves rigorous bug testing and is controlled by the Software Engineer.

I have read the FDA document "General Principals of Software Validation" which provides some guidance on source code evaluation but doesn't dictate who must do it. We review and evaluate the source code, however it is by the same person who wrote it.

Thanks
Simon

s.parakos,
First I view code review as a verification effort and not validation.
You are not required to have code reviewed. Code review is a way to show that the output of the coding effort meets its input (a design). (Code review generally does not show that the code meets the intended use of the product.) There are other ways of showing that the code output meets the design input. One way is with unit and integration testing run by the engineer. If you only have one coder, then I would suggest using unit/integration testing. Having the coder as the sole review the code would not be defensible as a code review. If you have another smart individual, you can improve the use of unit/integration tests by having them reviewed by someone else. The review of the tests can be at a much higher level than a code review by having the review of the tests against the design.
You can strengthen the process and your defensible position through the use of tools like static analyzers, and code coverage analysis.

As a software developer of 30 years I find no reason to look under the covers by non-programmer types. Some code can be 30 lines while others are 3000 lines; it just takes too much time to review. Rigorous repeated testing is the answer. Follow the planned script action review results. When obvious bugs/oversights are corrected and the programmer and validation/verification analyst feel everything is ok, THEN bring someone with little skills to test the software. I can guarantee they will find something just being new with application.

As a software developer of 30 years I find no reason to look under the covers by non-programmer types. Some code can be 30 lines while others are 3000 lines; it just takes too much time to review. Rigorous repeated testing is the answer. Follow the planned script action review results. When obvious bugs/oversights are corrected and the programmer and validation/verification analyst feel everything is ok, THEN bring someone with little skills to test the software. I can guarantee they will find something just being new with application.

I agree. I too write codes. And though it is not the 'meat' of my job i understand the difficulty of reviewing the codes line by line by someone other than the developer.

One question though:
I had one experience wherein a problem was encountered and after many investigations it was brought out that maybe the problem is either on the logic of the program being used by the machine to control the force setting , or the logic it uses to judge the product. This lead to a deeper question: 'Who reviewed the codes' ,'What was done to review the codes' , 'Any documentation of the tests done on the code' and other things.

Now my question is 'How do you qualify newly developed programs?' and 'How do you document User Acceptance Tests?'

Any idea?

Edit: In the problem above, the developer was an outside contractor. End user was Process Engineering. The guys who threw the question were QA people. Just to put things into perspective.

Ideally a code review would be conducted by someone as experienced as the author. However I agree that it can be a daunting task but a mix of review and testing can offer the best of both worlds. When there's lots of code, it can be prioritized so the reviewer(s) concentrates on the critical areas, which may be determined by risk analysis.

The benefits of review are well established and phrases such as "under the covers" make me shudder. The code should be open and detached from the ego of the author - this is another aspect that is helped by a review. The author and the reviewer(s) take a joint ownership role, depersonalizing the work and spreading the knowledge.

Lastly, reviews are extremely valuable when implementing a bug fix or minor feature. A quick review can save hours of retesting time.

If you want to make sure that review is of no use at all, then just follow the few simple rules described in the "how to write unmaintainable code" (I am not allowed to create links in here, so please ask Google for directions)