When software engineers have a problem with their engineering process, they solve it by writing software. Other engineering disciplines have it harder. Lacking instant automation, other fields accumulate ‘rules of thumb’ that they hope to maintain throughout the design process.
So it’s hardly surprising that the tools and processes software engineers invent for themselves emerge years before they enter mainstream engineering design thinking.
Tools like version control were among the first systems created by software engineers out of sheer necessity. Others have defaulted to elaborate workarounds, exchanging updated documents by email and tracking changes by adding version numbers to the file name.
But software engineering has so much more to offer: a culture of re-usability, team-based development, test suites, and code review. Few of these have seen application in full-force outside the discipline of software.
Why?
Because the rest don’t know what they’re missing. If the epitome of hardware engineering is to single-handedly design an entire board or module over several weeks and send it to manufacturing, it’s easy to forget what the world might look like if other talented colleagues were a part of the process. What if others could start incorporating your module into their design while you complete the layout? What if
they could run your latest test suite – or design rules – against their design to guarantee compliance? What if everyone on your team could continuously review the unfolding design, layer-by-layer, from their desk, and highlight problematic areas?
Did it ever occur to anyone that the idea of printing a picture of every layer of a circuit board on paper was ridiculous?
More than ever, hardware today requires engineers with wide expertise to be successful. Your RF guy, video guy and processor guy need to be able to work meaningfully together, in real-time. Because it’s not 1997 anymore.
Forward.
Upverter’s product suite is designed to address this problem. How can we lend hardware engineers the same empowering boost that software engineers were able to construct for themselves thirty years ago? How can we enable hardware engineers to be more agile?
Of course, they are different domains. Shipping software to the web is a considerably less risky prospect than shipping a prototype to manufacturing. But if more is at stake, we should be doubling down on tooling, on automated testing, on collaborative review. Even if the cost of prototyping isn’t problematic (and it often is), the opportunity cost is astronomic.
What if you could halve your number of pre-manufacturing prototypes? What if design review wasn’t a meeting to be dreaded by the team, but a routine, straightforward daily activity? What would this do to your competition?
Ultimately, shipping should be a celebration, not a fear. It should be a moment of certainty, of success, of comfort that you and everyone on the team has had total insight into the evolution of the product, and that every issue has been tracked, identified, and addressed.
And we think we can get there.
Upverter Blog 