A potential client wrote me recently:

“We developed software for a device, and now we need to make it IEC 62304 compliant.”

« head slap »

This isn’t the first time I’ve heard this.

The short answer is yes, I can help. It won’t even be too bad.

I’m going to go on a bit of a rant here, then I’m going to dial it back and remind myself (and you) that real people live in the real world and deal with messy problems, and they are doing their best, and sometimes you just have to suck it up and handle reality.

Rant starts now!

Software is code. Your code is not IEC 62304 compliant. It’s your process that needs to be IEC 62304 compliant.

The standard spells out how to create the process that you use to develop software.

  • You write, in a document, your plan for developing the software.
  • You write, in a document, what your software shall do.
  • You write, in a document, how your software will be structured.
  • You write, in a document, how your software will be tested.
  • You write, in a document, how you will handle bug reports.
  • You write, in a document, how the tests went.
  • You write, in a document, what you did to fix any problems identified in the tests.

There’s no code in those statements.

The code does not contain any information about the process used to develop it.

You can get a general sense of quality when looking at code, but you can’t tell whether it is 62304 compliant. 62304 compliance is not a property of the code. It’s a property of the process. It’s possible to produce exactly the same code when following IEC 62304 as when following no process at all.

What’s the point of following a standard then? The point is to demonstrate to others (and yourself), that you were diligent and methodical when developing your software.

Would you fly on an airplane if you talked to the software engineer who wrote the code for the flight computer, and she said “Process? I don’t need a process. I’m really good and careful. Just trust me.” I wouldn’t.

How do you know that you didn’t overlook something?

Are you telling me you had no bad days during the two years it took for you to write all that code?

So, when someone didn’t use a real process to develop code, or document any process when developing code, and then they want me to make the code “62304 compliant”, I die a bit inside. Because that’s just not the way it works.

Rant over!

Except, that is the way it often works in the real world. And, when I relax and think about it for a bit, it’s not so bad. Here’s why:

I’ve heard it said that the best way to write code is to write it once, throw it away, then write it again now that you actually know what you’re doing.

Of course, it’s also said that throwing away and rewriting code from scratch is a terrible idea. Far better to carefully and slowly refactor.

I’m really advocating the second approach.

When someone comes to me with code that they want to 62304-ify, that is “prototype” code. Prototyping is a good thing! It’s how you learn! They could have used that code to do all kinds of great things:

  • confirm that the device is technically feasible
  • give it to their target market and make sure it fills their needs
  • raise money to fund the company
  • do unofficial and formative usability studies
  • etc. etc.

You can sit on your high horse and complain that someone didn’t use the right process from the beginning, but maybe the only reason the company still exists at all to hire you is that they cranked out some prototype code in turbo mode. In the real world, there are tradeoffs. Getting a prototype done as quickly as possible, process be damned, is often the right way to go.

Plus, bonus, they’ve now written the code once through, and have learned all kinds of detailed technical lessons that will pay off when we develop the real version!

Wait, a new version? Yes.

I can’t take your existing code and make it IEC 62304 compliant.

What I can do is run an IEC 62304 compliant process from the beginning, taking full advantage along the way of all the wonderful lessons you learned from version 1. I can’t guarantee that the process will produce exactly the same code that ran on the prototype. Depending on the quality, we may heavily re-use code from the prototype. Or, maybe it really does mostly get thrown away.

If the prototype code actually satisfies all of its requirements, gets through code reviews, and passes all the tests, very little of it will go to waste. Any part of the code that does not meet those standards doesn’t belong on a production device, and wouldn’t have been usable anyway.

Regardless, when a client comes to me and asks me this question, they are where they are. If they could have done something better, I’ll be sure to tell them along the way so that they can do better next time. But, maybe, they did the best they could. Now, it’s my job to get them across the finish line, starting with what they have.

I’ll talk about exactly how to do this next time.