To understand the differences between hardware and software development and their respective schedules, we need to dig further into these differences between hardware and software iterations.<\/p>\r\n\r\n\r\n\r\n
Hardware iterations take time. A long time.<\/h4>\r\n\r\n\r\n\r\n
In both hardware and software development, an iteration loosely consists of design, build, and test phases.<\/p>\r\n\r\n\r\n\r\n
In software, many changes in the design and build phases do not introduce new dependencies outside of the engineer\u2019s control, and testing the result of a change is usually as simple as pressing a button to run the code. These factors are partly why the\u00a0majority<\/a>\u00a0of software development is\u00a0Agile<\/a>\u00a0\u2014 a strategy that optimizes for development speed by emphasizing flexibility and reducing excessive planning.<\/p>\r\n\r\n\r\n\r\n In an Agile framework, a software iteration \u2014 that time between \u201cI need to make a change\u201d and \u201cI know the result of that change\u201d \u2014 can take hours or less. A hardware iteration, however, takes about a hundred times longer.<\/p>\r\n\r\n\r\n\r\n The hardware\u00a0build<\/strong>\u00a0phase, which consists of both part manufacturing and product assembly, has the biggest impact on hardware iteration time. In order to test even a small component change in the context of the larger assembly, tens or hundreds of unique parts need to come together at the same time. Manufacturing these changed parts at pre-production quantities can take weeks for simpler parts and months for high-complexity parts requiring work from multiple vendors. The final assembly process can last an additional two weeks or more, depending on the quantity of units built.<\/p>\r\n\r\n\r\n\r\n Testing<\/strong>\u00a0each iteration also takes significantly longer for hardware. In addition to functional tests on the assembly line, most hardware products are subjected to a battery of mechanical and environmental reliability tests. Long-term environmental or life cycle testing can last months, but most results are available between a few days and two weeks after building.<\/p>\r\n\r\n\r\n\r\n Because of lengthy build and test phases, much more care must be put into learning from the previous hardware iteration and\u00a0designing<\/strong>\u00a0the next one. The hardware design process consists of brainstorming, modeling, detailed specification, and formal design reviews, and can take a couple of weeks. Most importantly, as we\u2019ll discuss below, multiple hardware designs are often fully planned in parallel, compounding the effort required during the design phase.<\/p>\r\n\r\n\r\n\r\n All-in-all, this makes for a months-long hardware iteration cycle. And since this cycle is so long, hardware engineers only get a few iterations to get their product right before it ships to customers.<\/p>\r\n\r\n\r\n\r\n Software development in an Agile framework enables flexible priorities. This can make any schedule fluid, but by using historical engineering productivity data, the timeline for an iteration or even a whole project can be estimated. Agile software development therefore does not follow a schedule \u2014 if anything, it predicts one.<\/p>\r\n\r\n\r\n\r\n Hardware development, on the other hand, resembles a\u00a0waterfall<\/a>\u00a0model with prescribed flow and cadence of each iteration phase. Each development build requires parts from many suppliers to come together at once, so timing and coordination is critical. Since component lead times are so long, hardware development builds are scheduled months in advance and there are fewer opportunities to to make changes over the course of a program.<\/p>\r\n\r\n\r\n\r\n When even a single part is delayed<\/a>, the testing, learning and redesign of every component can be delayed, too. In many cases, this leads to overall schedule slip, which has a chain reaction to future part manufacturing, product assembly, and even shipment to customers.<\/p>\r\n\r\n\r\n\r\n Unfortunately, to avoid schedule impact from build delays, hardware teams often attempt to compress the design, testing, and learning phases. Even worse, a program can enter \u201ccontinuous build mode.\u201d For hardware development this is actually a\u00a0terrible<\/em>\u00a0situation, with material and time continuously spent building with the latest component revisions. Both outcomes add risk to design and validation, and add stress to all engineers who are on the hook.<\/p>\r\n\r\n\r\n\r\n With relatively few iterations in hardware development, major issues need to be resolved by the next build to keep the schedule on track. But this explicitly violates the notion of \u2018iteration\u2019 \u2014 that you can try something and, when it doesn\u2019t work, try the next thing.<\/p>\r\n\r\n\r\n\r\n In Agile software development, backup plans, bug fixes, etc. are scoped on an as-needed basis. In particular, this means that feature iterations are designed, built, and tested serially. Plan B isn\u2019t usually started until Plan A has failed.<\/p>\r\n\r\n\r\n\r\n When problem-solving on a hardware build schedule, however, if plan A doesn\u2019t pan out, you better have kicked off backup plans B, C, and D already. This adds additional effort to the design phase of each iteration (and to the build and test phases, too), so it\u2019s important to understand which backup plans are worth investing in.<\/p>\r\n\r\n\r\n\r\n Large and small companies alike must be judicious about how they allocate time and money to these backup plans. For critical issues, hardware companies must decide between conducting additional, unscheduled experiments to learn more about a solution\u2019s viability (which often introduces delays) and spending the resources to kick off multiple solutions in parallel.<\/p>\r\n\r\n\r\n\r\n Each of these differences between hardware and software development\u00a0\u2014<\/em>\u00a0long iteration time, a set development schedule, and parallel iteration\u00a0\u2014<\/em>\u00a0all stem from the long hardware build and test phases. The result is a hardware development process with significant effort spent on planning and a high sensitivity to delays.<\/p>\r\n\r\n\r\n\r\n So what can hardware engineers learn from the world of software development? In a way, hardware development is already becoming more \u201cAgile\u201d with the advent of cheap rapid prototyping tools. These tools enable quick iteration of an early concept, but the benefits do not last into later large-scale validation builds.<\/p>\r\n\r\n\r\n\r\n For these later hardware development builds, we must reduce the iteration time in other ways. Software engineers accelerate issue finding and \u201cfailure analysis\u201d with debugging tools and continuous integration, but until now most hardware engineers have had nothing of the sort.<\/p>\r\n\r\n\r\n\r\n A system like Instrumental, however, provides a snapshot like a debugger\u00a0\u2014<\/em>\u00a0view into every unit<\/a>\u00a0during each state of assembly that engineers can step through to see where things went wrong. It also helps engineers detect issues earlier in the iteration process like a continuous integration tool, leaving more time to design and implement design changes with lower risk of schedule slip.<\/p>\r\n\r\n\r\n\r\n![\"Hardware](\"https:\/\/beinstrumental.wpengine.com\/wp-content\/uploads\/2020\/10\/blog5-1.jpg\")
\r\n![\"Design,](\"https:\/\/beinstrumental.wpengine.com\/wp-content\/uploads\/2020\/10\/blog5-2.jpg\")
<\/figure>\r\n\r\n\r\n\r\nHardware iterates on a schedule.<\/h4>\r\n\r\n\r\n\r\n
![\"Planned](\"https:\/\/beinstrumental.wpengine.com\/wp-content\/uploads\/2020\/10\/blog5-3.jpg\")
<\/figure>\r\n\r\n\r\n\r\nHardware \u2018iterates\u2019 in parallel.<\/h4>\r\n\r\n\r\n\r\n
What can hardware learn from software?<\/h4>\r\n\r\n\r\n\r\n