electronics manufacturing, hardware and software integration
developer at a hardware desk

The Intersection of Hardware and Software in Electronics Manufacturing

The intersection of hardware and software is well-worn topic that many people smarter than myself have examined and written about. At MacroFab, we live in that intersection. We manufacture hardware, using software we’ve developed, to direct the execution of the following:

  • Orders are uploaded through our platform by our customers
  • We dissect the order information and deliver it back to our customers, operators, and management
  • The information drives every step in assembly

More and more we are seeing software execute things that were previously manual. Hailing a ride or setting your thermostat are common examples. Many times, these applications can be somewhat simple to develop. However, assembling electronics from customer designs carries a great deal of complexity.   

At MacroFab, the software and manufacturing teams work closely to process our increasing numbers of orders while building more online tools to efficiently execute our process. This can be a time consuming process as both teams can easily spend all day, writing code or assembling boards – working in silos. Yet, in order to build a modern platform, we need collaboration.  Balancing between these two worlds is the biggest challenge of the job but also the area where we see the greatest impact.

hardware and software collaboration

The Software and Operations team working together to improve workflow and usability of our platform.


Building empathy

Empathy for the end user is critical to developing good software. At MacroFab our user groups are customers, operators and management and they use the platform in different ways:

  • Customers want an easy-to-use platform
  • Operators want the information they need for their stage of production
  • Management want to see a bird’s eye view of everything happening

Here are some strategies we try at MacroFab to deliver the end user’s needs.

Pen and paper processes from operations, aka the D&D method.   

The operations team may know what problem we want to solve, but not too sure on how to go about it. This is a particularly dangerous situation to pass over to our software team. If we don’t know what we want, then it is unlikely the software team will be able to provide an adequate solution. For example, we know we want to speed up the time it takes to program our machines. Automating this is the obvious choice, however, we rely on highly qualified machine operators to use their years of experience to make sure our orders are built correctly.  In order to improve the process without sacrificing the domain knowledge, we need to identify the rote tasks ripe for automation, while leaving the tasks that require expertise for the manufacturing engineers to solve.

On the operations side, streamlining our process is an ongoing effort so that we can effectively communicate to our punch list to the development team. We typically hypothesize the new process, and first roll it out without any software solutions. We use white boards, printouts, etc., to test out the new method. Then we let it breathe for a while. Sometimes we discover our assumptions aren’t the best outcome, but it’s all related to making progress. As we evolve the process, we ultimately settle into something that works for us; at which point, the hand off to the software team is informed and set up to be successful.

old macrofa

This whiteboard tracks our production schedule and it’s dependencies. This has since been automated and represented in our software platform.


Make the Devs do it, aka dogfooding

This method asks our developers to walk in the shoes of the user. Examples include submitting their own designs for production and sitting at the operator benches to conduct a task. This approach can be considered risky, since takes developers away from writing code, sometimes for a whole day. However, it is illuminating to see how people actually use the products. Developers can capture all of the little annoyances firsthand. Updating these small details really improves the overall experience. Often our greatest upgrades come from a single developer, annoyed with a feature, hacking it out after hours. As the builders of our system, the developers better understand the solutions available to us. A secondary benefit is it boosts the teams’ respect for one another. Operators love seeing someone else in the company trying to solder, or operate a machine. It conveys the idea the the software team truly cares about the work of the operators. While developers, experiencing the manufacturing challenges, have a greater level of empathy for the users.  

software developer at a manufacturing desk

This is a software developer!


Mastering the intersections between customers, software and manufacturing is the biggest challenge at MacroFab, but it is the primary reason we exist. We cannot hope to innovate in this space without constantly trying new methods. While we have made considerable strides, we look forward developing many more solutions for this industry.