Search the Elsmar Cove!
**Search ALL of** with DuckDuckGo Especially for content not in the forum
Such as files in the Cove "Members" Directory

Dead or Unreachable Code in Medical Devices (Medical Device Software)


ErikaP - 2010


In our company we have a policy not to have any dead or unreachable code within our Medical Device product. I recently got the question whether this is a requirement stated by a law and/or standard.

I was sure it was, but now I am unable to find any reference. Can anyone please help?



Staff member
Super Moderator
I'm not aware of any standards or regulations. I searched on the FDA Guidance for Software Validation and found a reference to "dead" code - that it could be found using structural testing (but didn't say what to do about it). I didn't (readily) find anything in 62304.

Clearly, the policy is good - you certainly don't want dead / unreachable code. There's always the potential for the execution path to get corrupted and vector into that dead code area. We always make that a focus of all our software validation efforts and ensure that none exists. It should be removed prior to formal testing. If the development teams feels they need to keep it in for future consideration, branch the code in your CM system and pull it out of the release branch. This requires more maintenance (merging) but it's better than a field failure as a result of executing "unreachable" code.

Note: I'm pretty sure that in C/C++ you can surround it with IFDEF and it won't get compiled into the executable code. That's common to keep "debug" code out of the executable without having to have a separate debug branch.


Quite Involved in Discussions
It is a really interesting question, these really make our head thinking and sharing our ideas, I like that. :)

First I think we shall define what we consider as "dead code".
Having these two words it indicates me first that this likely source code areas have never ever been used during the run of the software.
But if they are never ever been used during the run of the software why they are there?
Normally all source code shall have a software requirement, because they were created based on those requirements.
But if there are traceable software requirements backwards from the source code, than they are not dead codes, only the corresponding requirement was never ever been used during the run of the software.

I would exclude debug related source code, because debugging is a compiler option and accordingly my view, debugging achieved on the differently complied executables of the same source code and normally end user gets the non debug complied executables.
There can be a case, when the developer leaves source code level debug related source codes, but its human mistake leaving them in, and not discovering this deviation of the source code from the specification during source code review.

The other option I think may bring dead code in the picture is when there is a change in the software requirement or partial/full removal of software requirement elements and this action happens only on the specification level, incorrectly manage this change and leaving the code in the finished device. Actually it also not too likely in a CM environment, with labelling and sw integration plans it can be eliminated.

Sum it up, at this time, I believe when your design effort progressed accordingly this standard and you maintain integrity with the FDA Design Control, I think it can not happen.

Kind Regards


Staff member
Super Moderator

It happens all the time. Developers take one tack in implementing a requirement, decide it may not work as well as they want, and then put a branch around to a different implementation without going back and eliminating the dead code. Another way, they may put some 'hooks' in for future implmentation and branch around for the current implementation. There are plenty of seemingly 'legitimate' reasons for ending up with dead code.

Keeping debug code in the source should only be used if the debug code can be compiled out of the release (and tested) version (hence the IFDEF note in my previous post).


Quite Involved in Discussions
Yes, this is why it is important to define first what we consider as a "dead code".

I think the importance of this "dead code" from the quality prospective when the Design Output contains "dead code". But in these two scenarios it can not happen, they remains as a non integrated version controlled source file in the Configuration Management system.

Whether companies like it or not, they have to spend on CM systems and not only on license fees but the integration of its use into their QMS (having proper version control/source code labeling/integration protocols).


Involved In Discussions
It's not a directive but just smart to have no dead or extraneous code in the shipping set.Easier to remove it than to review it and test it or to justify not doing that. Move the code to other files.

This issue really points up the value of good requirements and design earlier in the project. And stable requirements as well.
Top Bottom