If you had to go about making a product that works on the first try, how would you do it? Even better might be the question why would you do it? It almost never happens, and when it does it is often joined by a short round of high fives and long round of working to dispel the ‘too good to be true’ feeling that inevitably follows.

“But, Nigel”, you might say, “there are plenty of engineering products that work the first time they’re built, like bridges or satellites.” In a way you’d be correct, but what you’re forgetting is the enormous amount of testing that goes on before they are put together.

Let’s borrow some ideas from the aerospace industry to find out why they would want to make a product work on the first try.

The motivation may be obvious to you: once a satellite goes up, it does not come down. There aren’t any repair or refit missions (except for the really expensive crafts, such as Hubble). The craft cannot be examined to see what went wrong or be refueled (yet), and you can’t just unplug it and plug it back in again. Fortunately, most satellites do work on the first try, but it isn’t just luck; the difference is that they do a lot of subsystem testing to ensure every sub-component works perfectly before integration. A lot of modelling and simulation is also done to ensure the interactions between sub-components are well understood. This is a massively expensive and time-consuming undertaking, but when the final spacecraft costs much more than the testing, it is a sensible plan for them to ensure nothing needs to be re-made.

In biomedical engineering we don’t have to hand over the first fully integrated unit and stop there, so the answer to the question ‘why would we build a product that works on the first try?’ is that we wouldn’t. It is much cheaper and faster to build several prototypes until they work, proven by industry in many famous examples. Additionally, instead of asking ‘how would we build a product that works on the first try?’ we must only ask ‘how do we build a product that works when it is released’. The device must perform perfectly eventually, but the final product won’t be, and shouldn’t be, the same as the early prototypes. The art of the trade is how to balance subsystem testing with prototype testing. In space science, it’s mostly the former, but for the rest of us it’s more like 50:50. Here are some questions to ask yourself before you switch from subsystem testing to assembling a prototype:

• Will it connect? Physically, electrically, and with software. Unless you build a test rig or spend a lot of effort in modelling all the components, the best way to be sure is to start integrating.
• Are you sure it won’t damage the rest of the parts? For example, don’t rush a power regulator in until you know it’s safe, or you’ll be ordering everything again.
• Are you testing functionality? It is important to test the functionality of subsystems before integration only so you have a benchmark as to how it performed beforehand. It’s better (to a certain extent) to do all testing in the final product, which will have to be done eventually anyway and is more likely to uncover interactions between subsystems.
• Are the key components ready to go? Without power, a brain, and I/O functionality the prototype will not work. These have to be ready first.
• How many prototypes are you able to make? The more iterations you can make the sooner you can get an integrated prototype together, and the faster you can figure out what’s not quite right. The trade-off of getting to prototype faster and saving time is often an increase in materials cost, this will affect each project differently.
• Can you create sub-assemblies? Add things one by one to your assembly until you have a full prototype. If there is an expensive part you are concerned about damaging, isolate it for as long as possible.

Most of these questions may be the obvious precursors to a prototype.  My point is to recognize when you’re ready to integrate and ask yourself why you haven’t done it yet!