How to Make Software for Hardware Engineering
The singular passion of my career has been increasing the broad competency of engineering hardware-based systems. My degree in mechanical engineering - though seemingly less relevant to my daily activities with each passing year - reveals my hardware-centric worldview. I identify as an engineer with an unerringly fierce pride because of an initial love for cars and machines, mechanisms that we can touch and in turn can touch the world. In my education and early career I glimpsed the elegantly perfect designs of very simple machines, an engineering process that discovers purity more than it invents optimums. But when designing a system of any complexity befitting the real world that perfect convergence vanishes and the experience of engineering complicated electro-mechanical-software devices becomes murky and clumsy. There has to be a better way, my better technical angels whispered in my ear.
As my daily engineering work transitioned from hardware- to software-centric I discovered a field of engineering that was still rapidly iterating on its process, striving for structure and transparency into systems that were spiraling into nightmarish complexity. Hardware's reliance on real world constraints might have been a crutch that software was never offered; the abstract world of bits is a chaotic greenfield into which structure must be introduced before true productivity can be realized. What's achievable in hardware is constrained by physics, materials, and manufacture; an engineer can hurl themselves into the process with the real world as a backstop to scope the project. What's achievable in software is a practically limitless abstraction that requires defining some practical constraints before anything useful can be done.
My vision of restoring control and elegance to hardware engineering will be realized by building software tools that can extend the engineer's brain and make complex systems malleable and tractable in the design process. Fortunately for the hardware types, we have a large, well-funded, and ambitious software startup ecosystem that is just itching to build software businesses to sell into other industries. This is terrific and the tools that this capital and labor builds may yet be what fixes everything I find insufficient about hardware engineering.
It unfortunately will not be easy. I've implemented both old and new software tools for century-old companies, built my own custom software tools, worked for startups building and selling software tools, and most importantly talked with dozens of startup founders trying to build these tools. There are some common mistakes, bad advice, and misaligned perspectives that remain stubbornly pervasive. Some are simply outdated common wisdom that refuses to die, some are misapplied lessons from consumer or intra-software industries, and some are being shared in bad faith by those with a conflict of interest.
So I offer these insights from my time on both sides of the divide, some gentle truths and best practices, in the hope that engineers in decades to come has the tools that we lack now.
If you wouldn't build software with it, we won't build hardware with it
Software engineering has a cultural and technical flavor, a set of common law values and processes that have stood the test of time. Software engineers carefully manage their data with fine-grained collaborative DAG structures and git tooling as simple or featureful as they'd like. Git offers a local-first paradigm, with granular merging, perfect data availability, and maximal control and ownership.
Yet the tools that developers often build for everyone else fail their own tests. They squirrel data away in an obfuscated cloud, are online-only or online-first, and offer rudimentary collaborative workflows. There are countless more examples of values that software teams hold as immutable but don't prioritize for their users. This has been an increasingly flawed perception for even technical-ish users; even teams of journalists are finding the collaborative features offered by Google's Drives and Docs don't hang with their increasingly power user flow.
Far from being prosumer, hardware engineers are deeply technical and working with systems and workflows that frankly blow a TypeScript webapp running on AWS out of the water and rival large-scale big tech infrastructure for complexity. Yet I still see software engineers building tools for hardware engineers as if their users are unopinionated technophobes.
If you would not build your own app with the style and flavor of tools that you're building for deeptech industries then we don't want them either. Any hardware company aiming to "techify" their processes with Silicon Valley-derived software is likely doing it because they want Silicon Valley-derived workflows, innovation, and productivity gains.
Engineering is a craft and tools are deeply personal to craftspeople
The individual developer experience is rightfully precious in software. As you read this, the vim vs emacs debate is echoing through an open floorplan office while ergonomic split ortho keyboards adorn convertible standing desks. Syntax color themes, keyboard shortcuts, windows tiling managers, and LSP-driven tooling are endlessly tweaked to realize maximum developer prowess. The keys to 10x developer efficiency probably aren't hidden in your VS Code config but all devs intuitively understand this to be a necessary ritual.
This is because while these fields are sciences they are also crafts, in the same lineage as stonemasons and blacksmiths and carpenters and machinists. The experiential throughline of all these vocations is the deeply personal relationship that the craftsperson has with their tools. A sheet metal panel former carefully weighs three identical-looking hammers before selecting the one with the right feel. Mechanics spend thousands of dollars to build the loaded tool chest that empowers them to repair anything they encounter. Machinists seemingly spend as much time fabricating their own tools and fixtures as they do actual parts. Hardware engineers - like software engineers - are no different and count themselves among this artisan guild of tool-wielders.
This should give you some appreciation for the significance of injecting your product into the relationship between craftsperson and tool. When your esteem and efficacy as an engineer is realized through the tools you wield they're both an asset and a liability. New tools are welcome, often necessary, but your work flows through these prosthetic extensions of your capability and the wrong tool can handicap or hobble. The decision is rational in part but also at least intuitive and sometimes purely emotional.
Not all pieces of software in the engineering process fall into this tooling category. Your IDE choice is personal while your CI/CD provider is likely more a matter of convenience. This holds in hardware engineering as well but be respectful of the first capability extension of an engineer: the CAD package, the software dev environment, the data analysis tool, etc.
Filling in gaps is easy, replacing process is hard
Especially with the current batch of AI-driven tools, there is a broad solution space that has never been open to software before. Some of the tech startups seeing the fastest growth selling into hard industries are finding a corner of the engineering process that simply could not be automated easily or without AI. They further hedge by not injecting themselves into the feedforward design path but the feedback path, adding an AI review or check to assure correctness. These companies are sometimes significant value adders, occasionally moderate snake oil, but they're all getting a shot because filling in a gap in the process is easy for both parties. "Sure, why not", the hardware manager thinks, "I have some budget, the boss wants me to try AI, I'll give these guys a year and see if it helps".
These tools may offer value but pitching a replacement for legacy tools is a fundamentally different ask. For the aforementioned reasons (personal tool interactions) and reasons yet to be elucidated (trust in infrastructure), an engineering organization with any expectation of deliverables will be highly reticent and skeptical to jettison a known inconvenience for a promising stranger. Understand it as a rewrite of your tech stack to a new and not-entirely-proven programming language or UI framework. It might look rosy at first but you're embarking on a long journey together and just like the rest of your team you need to know that your tools will hold fast under fire. This is the primary path, the daily process, the very essence of a digital model of a physical world. This is the big leagues and you have to build for it.
Infrastructure requires trust
There was a time before the great glowing eye atop a dark tower in Silicon Valley turned its spotlight gaze on hardware industries and that time was the age of B2B SaaS developer tools. New projects sprang up wrapping open source infrastructure in closed source deployments, picking off the untamed edges of the software development process. Yet even as the software industry commercialized itself a credo remained uncompromised; you don't build critical infrastructure on software you don't trust.
The easiest way to gain trust - especially for a new company - has been open-sourcing at least the core of the stack. Seeing that open-source project being used by peer companies allays one set of concerns, seeing a non-profit foundation maintain it further mollifies, and seeing an ecosystem of free and commercial entities emerge mitigates the risk all the way to a code green. Gaining trust in a closed- or single-source software requires years or decades of continuity and corporate scale; I'm not sure if we're even minting new trusted closed-source companies any longer.
The only trust historically available to hardware industries has been that of commercial might. Names like Siemens, Daussault Systemes, Ansys, and Mathworks are drilled into your brain in college with the faith that they'll still be around for the duration of your career. These industries are dabbling into open-source but their jurisprudence is well-founded. A passenger vehicle is in development for 3-5 years then in production for at least 7-10 and sometimes up to 20. Aerospace and defense projects extend that timeline into the decades. That's a set of CAD models, drawings, software repositories, and analysis documents that need a shelf life as long as many programming languages have existed.
Understand that when you pitch a company with that time horizon on a closed-source, cloud-based annual revenue SaaS project you're dropping a bigger and more nonchalant "trust me bro" on the table than you might realize. What's reproducability going to look like? Data portability? How robust is your infrastructure? Do they need to pay the SaaS bill for the decade of production even after the years of active development?
One way to mitigate this is by building a tool that just isn't mission-critical. Offer some nice assurances with an AI-driven feedback tool that your customers can enjoy but most certainly live without and this tense standoff of trust is barely an issue. But that doesn't sound like a very consequential piece of software and I don't think either of us want you to be building that. The arguably better option - the one that software has converged on with enthusiasm - is openness. Not just open-source software but open data and file types, data portability, and parsability. The anti-consumer practice of holding data hostage will not hold here. Get creative with your business model and maybe learn to tell your fractional CFO that SaaS is not a one-size-fits-all. Open-source the part of your software that your customers will need in a decade when you've moved on to the next startup.
I know you might be in a seed round trying to get a blitz scale uptick of growth to paint a picture of momentum for your VCs to go raise. You might be thinking about a runway in months but your customers are operating on a different timescale and criticality. Start by building infrastructure that at least meets the threshold of trust upon which you would need to build your technology and business. Then get ready to make even more assurances.
The cloud is more liability than asset
Not to say there are no benefits to cloud-based applications but as of this writing they offer more steps backwards than forward in these unique industries. They can solve some problems like collaboration, version mismatches, laptop hardware requirements like space and processing, and ease of deployment by the IT department. But those are largely consumer perspectives; the org already has repositories and PDMs, their engineers are already lugging around 17" beefy commercial laptops with discrete graphics, and the IT department is used to handling these hefty software packages.
Meanwhile the cloud is now introducing a lot of headaches. Offline use is a requirement for most areas of hardware engineering; remote launch sites, test tracks, or even far-flung corners of factories with poor WiFi. Your own cloud data storage model is probably difficult to synchronize with the multiple other data storage models in place. ITAR and data privacy control is a legal liability for anyone catching a whiff of defense work but even in the civilian markets control and protection of IP is omnipresent. Lastly, the large and well-established industry players might just have already built their own "cloud" with a rack of servers and internal IT.
There are nice applications of the cloud. The most obvious is targeting startups and midsized companies who have yet to build out internal server compute and storage. But that's putting a nice glass ceiling on your potential market unless you commit to also offering on-prem or self-hosted options. Perhaps there are even interesting features and quality-of-life improvements with clever applications of cloud features. But be honest and ask yourself; do you want to sell the cloud because your VCs can only think in SaaS terms or do you truly believe that's the best experience for your customers? Even if it is, are you willing to deal with the headaches of the plentiful downsides?
Don't decentralize design data
The monorepo is the favorite data structure of software projects because it allows colocation and alignment, with even FAANG-scale projects holding to monolithic structures. Imagine building complicated software systems where a half dozen repos all had to be "up to date". If that doesn't start the dull pain of a migraine throbbing behind your eyes then you're truly unflappable. Monorepos (or at least submodules), configuration as code, and maligned yet necessary build systems like basil and soong are all necessities for wrangling exploding complexity.
This level of control over the design data is hardly available to hardware engineers, instead splintering into domain-derived and vertically isolated silos. Proprietary CAD package specific data management servers hold hardware design, application lifecycle management servers hold requirements and test reports, and maybe a repo can handle some code if we're lucky. Servers or shared folders are stuffed full of stashed PDFs of datasheets and component specs because those are critical dependencies that can't be versioned or managed. Where file system storage is available the frustrating default is inscrutable binary file formats that can't be diffed, making any fine grained merging impossible.
This is a problem for hardware engineering but it might not be your problem (unless you can solve it, in which case please do). As a newcomer to this cacophonous din you do, however, have to be mindful to not add to the noise. Adding your own unversionable and inscrutable data storage bucket for the part of the system you want to solve for is one additional source of truth in an O(n^2) system. You can build some API integrations, maybe even call them out as value adding product features in your marketing, but realistically you're just mitigating the overhead that you're adding. Once again; is that how you would want to manage your own system complexity? If you can't work on or in an existing design data storage system the next best solution is the software solution; diffable plain text.
We want to build hardware more like software
Like any good reasonable moderate I often have the honor of debating both sides. I've spent many hours advocating for the very unique challenges of hardware engineering to tech industry veterans who are often naively unaware. But I'm not a luddite and I spend even more time with my foot on the gas. The gravity well that we're circling is clear and inevitable; the future of engineering hardware needs to look a lot more like engineering software.
The schisms between hardware and software processes are not opportunities for software tool vendors. They're the very problem statement that's driving large legacy industries to knock on the tech industry's door. Not everything transfers over but if you - a software developer - are asking what you can build that makes hardware engineering easier, I bid you to self-reflect on your own engineering process priorities and values. You'll still have to go ask about a million questions to the engineers in the hardware trenches but grounding your values in the openness, composability, and velocity of software development is a better square one than many of your competitors.