Hardware vs Software - Engineering Toolkit Comparison

Software engineering has become increasingly more agile and is built upon a set of tools that were purpose-built for every aspect of the job. Hardware engineering teams are working with tools that are 20 years behind their software engineering counterparts.

We compared 7 common workflows and the toolkits associated in both software and hardware engineering. We'd like to thank our friend Genie Kim, who has worked in both software and hardware, for providing excellent insight for this article!

1. Managing Design and Development Efforts
‍

Software

Software teams manage development environments with a branching system, where anyone can pull in another engineer’s branches to view or use it, and they all point back to ‘Master’. 

‍

Hardware

In hardware, engineers use a “check-in” and “check-out” system that often lead to async conflicts and version control problems. Determining what changed from one CAD file to another isn't trivial and can’t be done without intense manual work.

‍

2. Maintaining Revisions
‍

Software

In software, it's very easy to see what changed between a version. There is a clear record of who made what change (a commit history). Any revisions in one branch can be compared with any revisions on another branch and it's easy to visualize the difference.

‍

Hardware

In hardware, design iterations are often documented with a long string file name like "debossed_flange_D25__r1x6_Alx10" followed by post fixed revision names "r1", "r2", "r3", "final", "final2", "actually_final”. 

Rollback histories are often lost, and designers have models with similar file names that may actually be slightly different. To check, we manually inspect key dimensions. This makes it easy to send a supplier a visually similar but incorrect model with a radius of 5mm instead of 5.2mm if one didn't check that particular dimension before sending, and mixed up the “_copy” from “_copy(1)”.

‍

3. Design Documentation and Intent
‍

Software

In software, design documentation is integrated with the process with design intent and complex algorithms are explained as comments along the way.
‍

‍

Hardware

Most engineering work refers back to some set of requirements where all the updates and comments are done in the form of an email thread that eventually gets lost, or in person explanation, or in a slideshow.

‍

4. Access control and Sharing
‍

Software

In software, the team accesses each other's branches, with appropriate levels of authorities. Access is controlled, and simple.
‍

‍

Hardware

In hardware, rarely anyone is working off of the same version of the file at the same time. Most of the time, the designer has their own local copy of a model that they work off of. Which makes maintaining “divergence” really difficult and if models aren’t updated and fixed individually, they’re often left broken.

‍

5. Review Cycles and Conflict Resolution
‍

Software

In software, changes are reviewed by peers and approved using well-understood pull request processes. Before merging changes into a parent branch, the developer has a very clear understanding of what files conflict with what and has a way to resolve them easily. Changes that would affect the Master goes through rigorous QA and testing.
‍

‍

Hardware

In hardware, changes are often inspected visually by peers over their shoulder at a computer screen or in a screenshot. There is no way for the designer to “preview” how a change to a model affects the parent assembly. Changes that would affect master assembly can be missed, and master constantly needs to be maintained. Maintaining the master assembly in a working state is a full time job set up for failure.

‍

6. Planning
‍

Software

Almost every software development team uses a purpose built issue tracking system for planning. Most modern teams employ agile methodologies and everything is captured in one central hub where the team works from daily.

‍

‍

Hardware

Hardware teams execute most projects in a waterfall approach - despite the push to be more iterative. They plan their work in spreadsheets and generic project management tools then track issues, comments and actions in a combination of homegrown solutions and disconnected software.

‍

7. Ownership
‍

Software

In software, it’s easy to tell who owns what through recent commit history or owner’s files.

‍
‍

‍

Hardware

In hardware, it’s often word of mouth. Work is often repeated and knowledge isn’t always transferred.

‍

What Is Next?

‍

The difference between a hardware engineer and software engineer’s processes are night and day. Hardware engineering teams use tools that are 20 years behind their software engineering counterparts.
‍
This process affects the ability to get technology into the hands of people who need it. Together, we must find new ways to improve quality outcomes, lower product delivery cost, and launch faster.

‍