Software vs Hardware Development

October 6, 2021

When I was an engineer and project manager at Apple, I had the privilege of working on a team that sat at the intersection of software and hardware. The lines between software and hardware development have blurred as new companies produce more hardware that is enabled by software. This has given rise to new business models such as hardware-as-a-service (Vivint), and hardware enabled services (Embr).

The common saying is that hardware is designed and software is developed. Both are incredibly complex, but I would argue that the plethora of software tools available has made software development easier. The same can’t really be said for hardware.

1. Hardware development, especially when bugs come up, is oh so expensive

There are many costs associated with hardware. There is significant R&D and sunk cost if something goes wrong in development. It’s not uncommon for companies to recall all units due to a bug. In addition to the design, production equipment may have to be changed along with a whole new round of testing. That’s why companies like Apple spend so much money sending engineers to factories. My team spent many nights in China ensuring that bugs are caught before the EVT, DVT, and PVT stages.

Incumbent hardware tools such as Solidworks, Autodesk, Altium, and Cadence are also incredibly expensive. Software engineers can fire up a free IDE to program in and subsequently share their code on GitHub. Whereas hardware engineers usually sit in their own environments and lack the ability to share files outside of that environment due to licensing.

It’s much easier to fix software bugs as they arise. If there’s a software bug, engineers just have to turn their attention to resolving that bug, which brings me to my next point…

2. You have to be patient with hardware iterations, while software iteration is quick

The easiest example is to look at Apple. A new crop of iPhones are announced once a year while iOS goes through many iterations over the same cycle. Other companies such as Google and Microsoft follow a similar cycle. When I worked closely with the Apple hardware platform architecture team, conversations regarding a new generation of iPhones (as well as many other products) started well over a year in advance.

The reality is that the typical lifecycle of hardware can be painfully long. The ideate and design phase typically involves cross functional work with not only internal stakeholders, but also external partners, making the communication process even more complex. Then comes the build and validate phase, where companies finalize the manufacturing process and tooling as well as the testing and inspection of the equipment needed. Not to mention the long supply chain process to purchase parts as well as copyright, IP, and patent concerns.

Software development has become more complicated with recent developments of machine learning, and artificial intelligence. However, with countless open source frameworks available, the typical lifecycle is still relatively straightforward. It consists of a design phase where product requirement documents are written. Then the bulk of time is dedicated to development before the golden master (GM) release. Even after the design phase is over, developers and product managers can easily add or amend the product roadmap without much repercussion.

3. Agile methodologies serve software and hardware in different ways

Agile development is the rage of Silicon Valley. If you work in tech, you’ve probably heard of terms such as scrum, epics, sprints etc. The basis of agile is to divide the work needed into digestible chunks that can be delivered in specific time frames.

For software, that comes in the delivery of new features that build up into the full product over time. As for hardware, it's difficult to translate into user stories, epics, and different buckets that agile "forces" teams to do. Often times, there isn't much to update in daily stand-up meetings (a staple of agile) because engineers have to wait for parts, prototype builds or test results. As a result, engineers can feel like they're being forced to use a specific framework that just doesn't work for them.

Unlike software, hardware does not operate in a “just in time” model of small increments. Therefore the famous Facebook mantra “move fast and break things” just simply won’t work as well. That being said, there has been a movement towards a modified agile for hardware development as seen here.

Incumbent hardware tools such as SolidWorks, Autodesk, Altium, and Cadence are also incredibly expensive. Whereas software engineers can fire up a free IDE to program in and subsequently share their code on GitHub, hardware engineers usually sit in their own environments and lack the ability to share files outside of that environment due to licensing.

4. The job of a hardware engineer isn’t just limited to development

For companies that don’t out-source development, software engineers don’t have to interact with external parties such as vendors or consultants. With complex components such as assembly, optics, circuitry, and packaging, hardware engineering is traditionally more externally collaborative. It was common for engineers at Apple to be on huge email threads and drawn out alignment meetings with contract manufacturers (CM) and suppliers to iron out issues.

Quality assurance (QA) in the software space has also become incredibly easy with the plethora of open source tools and tooling options. QA teams are also typically separate from the development team. However, in hardware, QA is commonly done by the product engineers themselves.

5. There is still a lot to be desired with today’s hardware processes

At Apple, we used screenshots, email chains, PowerPoint, and Excel to share design files and the typical hardware company today is no exception. Because these tools are not designed to accommodate the visual aspect of hardware designs, they often lead to miscommunication and information disaggregation. Jira and Asana are not good options either due to the focus on software workflows and text-based code.

Many hardware managers emphasize the importance of good team processes to ensure that engineers are spending time on engineering work in order to minimize design/production risk. This is why at Bild, we envision a future where engineers and hardware teams can easily share and collaborate on visual assets on an integrated web platform.

If you have any questions regarding how Bild works, please don’t hesitate to reach out to us at!