Development of hardware and physical products can learn from the software industry
Engineers in mechanical, electrical, and software disciplines, as well as operations professionals can learn from understanding different development processes. I am going to draw some parallels here in order to bridge the gap between these fields and inspire ideas for applying software development concepts to hardware development, and the way software platforms for the hardware industry are being built. For simplicity, I will use the term hardware development in this post to incorporate physical product development, and any mention of hardware tools means software that is built for hardware development.
For some context, last year I left my job as a software engineer in order to start a company building a PLM (product lifecycle management) application, which sits at the heart of product development process. I have been programming software for quite some time, and being interested in hardware I started to compare some of the differences between hardware and software development with a few of my Mech Eng and EE friends.
Having had some time conducting extensive interviews, building a barebones PLM, and extending that product for the last few months, many of those initial ideas have evolved substantially.
PDM + PLM ≡ Git + Github + Dependency Management
The lines between PDM (product data management) and PLM (product lifecycle management) are distinctly different than between Git, Github and dependency management, however grouping these together in each sector is a fairly decent analogy.
In software, engineers are often able to create, review and deploy code with very little interaction with other teams
Git and a Git remote is used to collaborate and synchronize changes onto the cloud, just like PDM. In both cases, this is for work in progress, which is reviewed before it's ready for production. In the case of Git, changes are saved to a specific branch that can later be merged with other changes in the main branch. PDM is generally more linear, akin to multiple engineers collaborating on a single staging branch. To support branching and merging in PDMs, CAD tools would need first class support which is why it is not a common feature (however OnShape does this pretty well!)
Once a branch's changes are ready in Git, a user opens a pull request to merge them into the main branch. In PDM, each part's revision is tracked, of which any can be pulled into a change order in a PLM. In PLM, change orders can contain changes across different projects at the same time, whereas Git based version control only support one project at a time.
In software, only certain components (i.e. Projects) can be reused, in hardware every component is reusable
A big difference is managing components (or "dependencies" in software). In software, components need not be named or versioned until they need to be used in more than one project, and if it is used elsewhere then using an older version is not a problem. In hardware this is much more complex; every component needs to be identified (often using a unique part number), and when they are updated, older versions should no longer be purchased or manufactured, implying every reference needs to be updated. There also needs to be a plan for what to do for the deprecated parts in the factory. Mistakes here can be incredibly costly, which is why it is surprising that companies continue to use spreadsheets whereas software engineers would be considered eccentric not to use Git + Github for much more straightforward development.
Hardware CAD revisions could be compared to a git hash, which defines a project at a certain point in history. Typically the version of a software project is managed separately from the hash, and set deliberately to communicate the kind of changes that have been made (see semver). The hardware world has a similar system, although there is no generally accepted format and process like in software. Hardware version schemas can use 1, 2, or 3 part versions, and in some cases the revision is used directly in the PLM instead of a decoupled version. This can be problematic when changes need to be made to parts in the PLM, which would not cause the revision in the PDM to be incremented (workarounds include back-propagating revisions into PDM).
Hardware development software is highly fragmented
Many PLMs are very difficult for engineers if they aren't using a certain CAD tool. For EE's and ME's to collaborate, there are very few options.
In hardware development, there are a large number of different software tools, each of which have completely different philosophies. This is in contrast to software, where almost everyone uses Git, and Github is used by the majority (there are Github alternatives, but the user flows are almost identical).
I have some ideas for why this is the case
CAD file formats are proprietary whereas software is written in plaintext. There are some programming IDE's that have language specific features, but the source is still plaintext. CAD files on the other hand are binaries. They can be converted and moved between CAD programs, but this is far from perfect and isn't practical. This causes CAD lock in, and causes massive fragmentation in downstream tools like PDMs and PLMs.
Hardware tools are targeted at either engineering or supply chain, and rarely both. In software we have platform engineers for ensuring code is delivered to customers, but they are mostly building reusable systems and do not need to understand much about what they are deploying (except some high level details). Because of this relationship, platform engineers are expected only to enable software engineers. In hardware, supply chain are involved in delivering each individual part, which is critical and highly complex. The market of software for hardware development has responded by building platforms specifically targeting supply chain users, even to the disdain of engineers that have to use them every day.
Fragmentation reduces the quality of tools on the market
Choice is always good, but software is expensive to build. If the market is fragmented then a) more time is spent by engineers integrating different tools, and b) it is unlikely software companies will have enough resources to fund a well finished product.
If tools can normalize the flow of data between different CADs and PLM, and create a great experience for both engineers and supply chain, then perhaps fragmentation could be overcome.
Software for hardware development uses outdated UI/UX practices
Specialized UI configuration is worse for everyone
The industry requirements and processes can be so different in hardware development that most tools rely on complicated custom configuration to support everything. This leads to a long onboarding time, and a buggy UI because engineers have to support a broader code base, with features that are barely used.
By understanding different requirements upfront, and putting more thought into developing the product, more use cases can be supported without custom configuration. This makes product development far more challenging, but is a well known concept building software applications.
No Solid UX philosophy
Hardware tools tend to be more like databases with a frontend. User's are assumed to be technical and well trained and this approach leads to mistakes and reduces collaboration between teams. In software development tools, it is more clear what is outstanding, what needs to be done to move forward and the UI/UX teams agree on certain philosophies to help users achieve their goal.
Well designed change view reduces mistakes in the review process
For example, in a GitHub pull request, the activity feed helps any user looking at it understand exactly what is going on. The changes are very clear, and can be represented side-by-side, where every change is guaranteed to be seen by scrolling. PLM change orders in contrast often attempt to show changes using large tables, and hide information between tabs or sliding panels.
For tools built to improve accuracy and collaboration, UX is everything.
Eventually, hardware development will improve
At some point a platform (or platforms) ought to arrive to serve this space better, but the environment and incentives mean that it may take a while. In software, it took the open source project, git, for Github to be viable. Perhaps, alike software, subtle improvements in parts of the hardware development stack can drive a revolution.