I’ve struggled with what to write in the past week. Concerns that seemed so pressing just one week ago are now distant memories.

Still, life doesn’t stop, and it’s important that we all make the necessary changes and then keep working as best we can.

I’m going to continue to write about medical device software development, with a bias toward topics that help medical device developers navigate this new reality that we are facing.

To that end, I’ll share a story about a project I’m currently working on.

Working remotely with hardware

I work from home.

At the moment, I’m developing firmware for a surgical tool for a client. Next to my desk, I have a classic prototype setup for embedded device development. Boards screwed to a sheet of plywood, with motors and switches clamped down and wiring harnesses going everywhere.

Late last week, I was probing one of the connectors, and I accidentally shorted a pin at 24 volts to a pin connected to a digital input of one of the microcontrollers.

Boom. No more microcontroller.

Ok, it wasn’t dramatic. There wasn’t even a pop or smoke. But, the entire setup is now useless, at least until I get a new board, because I can’t test my code on the device.

If I worked in an office, the solution might be as simple as walking over to the supply cabinet and grabbing a replacement board (sheepishly explaining my mistake to my coworkers).

Since I’m working remotely, I’m out of luck, for at least a day, if not several days.

As it turned out, I indeed was not able to get a new board for several days. Sure, I could (and would) write code in the meantime, but if I can’t test it as I’m developing it, it’s likely that it will be a painful afternoon of integration and bug-hunting when I finally try to test several days of coding all at once.

Test-Driven Development to the Rescue!

I practice Test-Driven Development (TDD), which means that I write comprehensive unit tests as I’m writing the code. When I finish coding a software module, I have a high degree of confidence that it works, even before testing it on the device.

TDD has several advantages, which I’ll talk about at length. But, for our purposes today, TDD has a very compelling advantage:

I can make significant progress without testing on any hardware at all.

Blowing up a development board didn’t stop me. I lost barely any time.

Are your developers working from home, without access to hardware?

Don’t have enough prototype boards to go around?

Test-driven development can help.

Of course, it’s not as easy as flipping a switch. If you’re going to implement TDD at your organization, there are a few technical hurdles to overcome. More importantly, there are significant cultural hurdles to overcome. TDD requires a new mindset and a new way of working. It’s an investment, one that can be particularly difficult to make in the current uncertain environment.

I strongly believe it is worth it. I personally made a significant investment in time and money to be trained on how to do test-driven development correctly. I can tell you from the other side that the investment has paid off handsomely.

Get in touch if you have questions.

Good luck, help each other, and stay safe out there.