Why hardware + software development fails

Hardware and software together form one of the most powerful ways to interact with an environment. The potential is enormous. Executives see the business opportunities, the technology looks feasible and the plan seems straightforward: allocate money, assign engineers, set timelines and watch the product come to life. That’s the high point, however.

From there, projects too often spiral downward. Deadlines crumble, costs soar and progress grinds to a halt. Meanwhile, leaner startups, often with fewer resources, are racing past, delivering working systems to customers. This isn’t an isolated story. Tens of thousands of projects have died this way, and thousands more are limping along right now.

So why does this happen?

Before diving into the causes, it’s important to recognize one core reality: I believe software is never “done.”

Unlike hardware, software can always be refined, optimized and extended. Each hour of development typically creates additional hours of future work. If that multiplier (call it “X”) is greater than 1, you’ll never finish. The key to success is learning how to manage X: knowing when to stop, when perfect is the enemy of good and how to deliver a product customers will value – even if the code isn’t perfect.

With that principle in mind, here are my most common and most costly reasons that hardware + software projects fail.

Unreasonable timelines

Overly aggressive schedules don’t just slip; they sabotage entire projects. Engineers under deadline pressure cut corners, taking shortcuts that undermine the foundation of the system. The work may look fine at first, but once all the components come together, the cracks spread quickly.

Sometimes the product limps across the finish line. More often, the whole effort collapses. Either way, setting an impossible timeline never saves time or money in the end. A realistic schedule from the start is always faster and cheaper.

The mythical man-month

This longstanding issue, first coined in 1975 by Fred Brooks regarding the development of IBM’s OS360, represents a miscalculation of labor needs. When a project starts slipping, a manager’s first instinct is to add more people. This is rarely helpful. A project has an ideal number of people; adding more people past the ideal number always makes things worse. 

Communication between people incurs real cost, from the communication needed for both the initial learning curve and continued development. Simple decisions require consensus. This is absolutely punishing to the value X (as stated above). Costs explode, timelines crumble. Everyone is unhappy. 

Building the product first

Another common mistake is charging ahead with building the “final” product right away. The problem is that most of the effort in hardware + software development isn’t in construction, but in resolving unknowns: unanswered questions about behavior, integration and real-world performance.

If you design the final product first and then task engineers with solving those unknowns inside it, you’re setting them up for failure. A better approach is to build a system designed specifically to answer those questions first. Only then should you move on to building the product customers will use.

In practice, if you are doing it right, about 80% of the time lies in solving unknowns, and only 20% in building the final product. Optimize to hit that 80% goal. Otherwise, it will take 100% of the time of your unfinished product. 

Draconian IT policies

At many large companies, restrictive IT rules quietly strangle productivity. Policies designed for office workers or pure software teams often conflict with the needs of hardware + software development.

Developing these systems is literally a process of iteration. Try something, see what happens, try the next thing. When engineers spend hours fighting with security rules, incompatible tools or clumsy workarounds, each iteration takes much longer, and progress slows to a crawl. Companies with the resources to tackle the most complex projects in the world often fail because their IT environment makes X explode. 

If you want innovation, stop pretending you can pair complex development with one-size-fits-all IT restrictions. You can’t.

Misused frameworks

Frameworks can be helpful, but they come with trade-offs. A framework, versus an operating system or library, does not perform a unique function. Instead, it exists to lower the learning curve by making a complex system simple. However, complex systems are complex for a reason, and a simplified version will not be as capable. Eventually, the system crosses a threshold of complexity, and the system doesn’t fail gracefully; it fails in unpredictable, messy ways.

For beginners or small test projects, frameworks like ROS (Robot Operating System) can accelerate progress. But for teams with deep expertise, an accelerated learning curve holds no value. Instead, frameworks often slow down development. Worse, when projects outgrow the framework, costs and timelines explode.

Testing blind spots

I see testing as the boogeyman of hardware + software projects. Done poorly, it derails everything. Problems could stem from the hardware, the software or even the physical environment. And without the right testing strategy, you’ll never know which.

Test too little, and the product will be unreliable. Test too much, and you’ll never finish. Test incorrectly, and you cannot differentiate among software problems, hardware problems or the physics of the device. The only way forward is to establish a clear testing plan before development begins, one that balances rigor with pragmatism and covers the interplay of hardware, software and the environment.

The path forward

Hardware + software development will always be difficult. But difficulty isn’t destiny. I believe that the companies that succeed are the ones that:

• Set realistic timelines.
• Respect the communication costs of scaling teams.
• Solve unknowns before building final products.
• Create IT environments that enable, not hinder.
• Use frameworks wisely, or not at all.
• Treat testing as a core discipline, not an afterthought.

Failure stories are common because pitfalls are common. But so are the opportunities. Companies that get this right can move faster than their competitors, deliver reliable products and unlock enormous value.

The next wave of transformative products won’t come from companies that repeat these mistakes. It will come from the ones that master the fundamentals of hardware + software development, supported by strong, empowered leadership and teams, to finally deliver on its promise.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?