Why is Hardware Design Hard? (Part 1)

I have spent the last year picking apart the engineering process and trying to figure out some ways we can improve the way we design and develop hardware. This is the first part in a series of posts discussing the problems we have found and how we plan to solve them.

As a founder or an engineer developing hardware, you’ve probably heard the phrase “hardware is hard”. Whether you are starting a company, launching a new product, or responding to a proposal, it is no secret that designing and developing hardware is a time-consuming process. But why is this? Why does it take so long to design hardware products?

Imagine trying to design a satellite from scratch. Unless you’ve worked in the space industry for many years, this can seem…well, like rocket science. When I found out about NASA CubeQuest, a cube satellite design competition, I was in this exact situation.

Just so we’re all on the same page, here were my qualifications to design a satellite: 1) I had taken physics classes, 2) I knew how to use Google.

In other words, I had no clue what I was doing: no formal training, a basic understanding of physics and math, and no funding. But so what? Mark Zuckerberg didn’t take any social media development classes and still figured out how to make a great product. How was this any different?

My team’s early optimism was soon met with a healthy dose of reality. Before we knew it, six months of designing went by, the first of four design deadlines was on our heels, and we still had no clue what we were doing. After a few all-night design sessions, we finally scrapped together a response and submitted to NASA for review. Getting to this point was no small feat, and although we eventually became one of the top teams in the nation, there was a lot of friction on our way to get there.

But the hardest part wasn’t the rocket science (in fact, that was relatively straightforward). Instead, our challenges all revolved around inaccessible engineering information. From finding the initial technical knowledge we needed to managing our team’s engineering data (e.g. spreadsheets, requirements, Matlab code), we were always on a wild goose chase to find the right information before the deadline.

Problem #1: Information is scattered and inaccessible.

Most modern hardware applications require a deep understanding of multiple domains. Take a modern fridge, for example. Many new refrigerators are becoming “smart”, with a giant tablet on the front to help track groceries. This means that fridge engineers need not only master the laws of thermodynamics, heat transfer, and advanced manufacturing, but also the accompanying electronics, control systems, optical equipment, image processing, and control software. Fridge engineers aren’t alone — the same increase in complexity has happened across hardware efforts in various industries.

(Image: hardware project complexity has increased dramatically since the 1960s | Source: DARPA)

The problem is that most people go to university to study only a small subset of these topics. So to design something like this, engineers either need to teach themselves the necessary skills or hire a large team of expensive, domain-specific engineers.

If you’re a small company without the funds to hire a huge team of engineers, you will have to fall back on the other option and crack open a textbook. Although there is great information that exists on the web, most of the technical material necessary for complex system design is still only available in textbooks. So your plan for finding the right information might look something like this: first, try and Google it, then once you can’t find it, figure out which textbook is the right one, shovel out hundreds of dollars to buy that book, wait for it to arrive, and hope it has what you are looking for. If it does, you’ll then spend days taking its contents and creating a spreadsheet or Matlab script to recreate the physics modeled there (if this process sounds frustratingly familiar, you’re not alone: 83% of engineers still frequently use spreadsheets and documents to make design decisions). Only then will you have your answer.

Sometimes you’ll get lucky and find the information on a website or an online paper, but it still needs to be transferred into a spreadsheet or script to model the physics. Or maybe you are really lucky and work at a large company where similar analyses were made before. It may still be somewhere on their server, which saves you hours of work; however, just to be safe, it’s a good idea to check the work to make sure that it was done right. And if you have any questions, hopefully the original engineer is still at the company. If they retired or they won the lottery and quit, you might just redo the work entirely.

What does a world look like where information is accessible? One only needs to look at our software engineering friends for inspiration. If you needed to program an app from scratch, for example, you would be greeted with a buffet of online support. The Internet has a wide variety of relevant code libraries and industry-supported frameworks that demonstrate how prior developers approached and executed their task.

These code repositories like GitHub don’t just enable sharing and iteration from previous work — they encourage it. In fact, these tools have become standard ways of documenting and sharing work among software teams. As a result, software engineers don’t need to track down their lottery-winning colleague or purchase an expensive textbook to figure out how to develop an app, nor do they have to start from square one every time they start something new. Everyone has immediate access to an enormous repository of work by engineers who have solved these problems before, allowing teams to spend most of their time improving on them or solving new problems.

In a team setting, especially, this system is much faster because it cuts out all the time and cost of waiting on colleagues to finish their parts of the design. There is also complete transparency, as you can see exactly who made what changes to the codebase and when they made them. Finally, software work is self-documented: the code is the documentation. Or in other words, software engineers don’t waste there time trying to document their work, they write their code in a way that any engineer can review and know immediately what is going on. Of course, they have to document their software to some degree, but it is far less than the extensive proposals and reports that hardware engineers must write. This can be achieved since the entire system architecture is in one place, and if written properly, everyone can trace the entire thought process — from the first line of code to the most recent update.

In the case of hardware, though, it’s not that teams don’t want to share work. There just aren’t many ways to do so effectively. The design tools that are currently available are still cumbersome, limiting effective information sharing and collaboration across teams. Across the hardware industry, there isn’t a standard method for sharing calculators and physics models, so it’s hard for teams to share and find the exact information they need.

Could a repository for hardware designs help? What would it take to get there? What would our industry look like if engineers shared common tools and calculators?

Over the next few weeks, I’ll be writing about some of the recurrent problems we face in hardware engineering. Stay with me as we look at why hardware design is so hard, why our methods haven’t changed, and what we can do to fix this. Also, if you have any suggestions on how to solve this problem or opinions on sharing technical knowledge in the hardware world, please comment below!