Iterate hardware like software

One of my favorite blog posts by @bradfa:

I’ve been doing some thinking on this subject lately and have concluded that the more complex a system is, the more important good collaboration and iteration models are.

I’m not actually sure if my final sentence is accurate, or ever was accurate. I have no idea what Apple does, they may not behave like this at all.

But at a former employer I, and my teammates, convinced our boss to try this and it was awesome. We had like 7 revisions of a prototype board over 9 weeks. We would order PCBs for 3-4 day turn, including shipping, and we had an awesome technician who would paste, hand populate, and reflow 2-3 of them each week for us. Digi-Key and Mouser supplied probably 90% of the parts and the other 10% came from other ordering methods.

At any point in the project we could take a full set of design files and get them quoted at CMs. As an engineer, your boss will love this. You can get real quotes for a real design and you can see how those quotes change over your design iterations for real, as you’re not asking hypothetical questions to your CM (“What if we change from 4 layers to 6?” but now you can really find out!).

One of the unsung awesome features of iterating hardware like this is the hardware team can try things they wouldn’t otherwise try. If you are designing something and you know there’s going to be another revision, then you’re more likely to try out ICs, layouts, or new circuits. On those 7 iterations we did in 9 weeks iteration number (iirc) 5 had some crazy extra voltage regulator on it because another project wanted to qualify it, so it just got stuck on since the board was getting ordered anyways, and we knew that design wasn’t going to be the final one. We tried lots of different RF circuits, probably 3 or 4 completely different antenna designs. We spent 0 time designing the first spin RF path because it didn’t matter even though the product was an RF product. Getting first hardware with approximately the right microcontroller and some of the right peripherals was more important to keep the firmware team moving.

It was great! It’s high pace and can be stressful, and you need a good way to track each revision’s changes, but holy cow you’ll progress very quickly to a sell-able product.

Obviously having smaller and simpler designs will improve your ability to iterate quickly, but some of that can be brought to more complex systems by distributing the system across multiple boards, too.

Thanks for sharing your real world experiences – super neat you got to try this.

I still like the last line of the article :wink: – pretty sure you are right on with that – how else can they reach that level of polish? Even with extensive modeling, there are some things you never learn until you try to put something together.