Are You Riding a Dead Horse?
A well-known adage attributed to the Native American wisdom advises: “When you find yourself riding a dead horse, the best course of action is to dismount.”
While the origins of the saying are uncertain, it frequently appears in business and humorous contexts to illustrate the futility of persisting with failed endeavors.
In the world of embedded systems development, projects don’t always go as planned. As a grey-haired embedded engineer, I am often brought in to recover projects that are already in deep trouble. This persistence often stems from the sunk cost fallacy, where organizations feel compelled to continue investing in a failing project simply because they have already spent so much on it. Many of these cases are classic examples of the “Dead Horse Theory” in action: organizations that continue to invest time, effort, and money into a project that has already failed, instead of acknowledging the reality and making necessary changes.
Real-World Dead Horse Cases
Over the years, I have encountered numerous projects where companies refused to let go of their “dead horse.” Here are a few anonymized examples.
The Wrong Hardware Choice
Some organizations, especially those lacking embedded systems expertise, default to using x86-based platforms or Raspberry Pi for everything. Running Linux on an undercover PC does not make it an embedded solution. Unless there are specific needs, such as integrating with a Windows infrastructure, using an embedded PC as a generic workhorse often leads to failures due to inefficiencies. Jack of all trades, master of none.
The Impossible Hardware Migration
What started as a well-intentioned plan to quickly prototype an MVP on x86 and later transition to a more suitable embedded platform turned into a nightmare. The team attempted to port their software across radically different platforms, underestimating the complexity of the migration. Keeping the legacy peripherals or using a completely different set usually doesn’t change the consequences of not allocating time for proper architecture redesign and software alignment. The horse may not have been dead, but it was hopelessly lame.
The Wandering Horse
Some projects never make it to market because they lack a clear specification. With no well-defined requirements, the development process meanders endlessly, much like a horse grazing aimlessly instead of heading toward a destination. Features are added and removed at random, requirements shift continuously, “patches” and “quick fixes” come and go, decisions are made reactively rather than strategically and never address the core issues. Without a concrete goal, the project stagnates, burning through time and resources without ever reaching a viable product.
The Legacy Code Trap
A company was determined to modernize a 20-year-old firmware stack without refactoring it, leading to unmanageable technical debt and spiraling development costs. Everything had changed since the original firmware was written: the CPU, the OS, the frameworks, the filesystems, the I/Os, the development team, and even the tools and methodologies. Yet, the expectation was that the firmware stack would remain unchanged.
The number one excuse for falling into this trap? “We’ve been doing it this way for decades. We just need a better wrapper.“
This mindset ignores the evolution of technology, methodologies, market demands, and regulatory requirements. Instead of adapting to new best practices, the company clings to outdated systems, making their codebase increasingly fragile and resistant to change.
Ten Classic "Dead Horse" Management Strategies in Embedded Systems
Let’s examine some typical ways organizations try to “revive” a dead or dying embedded project—and why these approaches rarely work.
Buying a stronger whip – Developers are pushed to work overtime to “make it work.” Sadly, bad architecture cannot be fixed by adding more effort.
Changing the rider – A new project manager is hired, but the fundamental technical problems remain unsolved.
Forming a committee to study the horse – Endless meetings and reports analyze the failing system, but no radical action is taken to replace or redesign it.
Arranging visits to see how others ride horses – Management looks for case studies of companies that allegedly succeeded under similar conditions, ignoring key differences in context.
Increasing funding to the horse – More budget is allocated to consultants, tools, and resources without addressing the root cause of failure.
Reclassifying the dead horse as “living-impaired” – The project is reframed as a “learning experience” to justify continuing development without admitting failure.
Outsourcing the horse-riding task – A contractor is brought in to fix the problems, but without addressing the underlying issues, they can only do so much.
Hiring consultants to analyze the dead horse – An expensive expert review confirms that the dead horse is dead: the project needs a fundamental redesign.
Lowering standards so that dead horses are considered acceptable – When all else fails, redefine success. The team convinces itself that an underperforming, bug-ridden product is “good enough” to ship, ignoring long-term maintenance risks and potential customer dissatisfaction. In extreme cases, they go a step further, claiming that the faulty product is actually superior because it is now “simpler,” “more efficient,” or even “cost-effective.” A dead horse ain’t eatin’ no hay anyway, right?
Killing your own horse because you either need a carriage or a pony – Sometimes, the real issue is that the original choice of platform or approach was completely unsuitable. Instead of persisting with a doomed architecture, the best solution might be to pivot entirely—choosing a different system that actually meets the requirements.
Why Do Horses Die?
The root cause of premature death can often be traced back to the sunk cost fallacy. Managers often refuse to admit failure, getting trapped in their original commitment. This is especially dangerous when the shortcomings appear at the lower levels, such as hardware. Instead of reconsidering the foundation, the team is pressured to move forward and incentivized to develop software workarounds—efforts they soon regret. A hardware bug must be fixed in the hardware.
Another common mistake is the assumption that changing software is quicker, cheaper, and easier than changing hardware. This belief is often plain wrong. While software is flexible, it cannot compensate for fundamental hardware shortcomings. Trying to “patch” hardware limitations with software frequently leads to bloated, inefficient, and fragile codebases that introduce new risks and performance issues. You can’t make a racehorse out of a loaded mule.
Even with the best intentions, embedded projects also fail for common predictable reasons. Here are some of the most frequent causes:
Unclear or shifting requirements – Without a well-defined specification, projects drift aimlessly, accumulating technical debt and inefficiencies.
Underestimation of complexity – Many projects fail because teams assume that hardware migration, software rewrites, or scaling up an MVP will be straightforward.
Ignoring technological evolution – Sticking to legacy approaches without reassessing newer methodologies, frameworks, or architectures leads to stagnation and inefficiencies.
Poor hardware selection – Choosing the wrong platform due to familiarity or short-term availability creates long-term constraints and incompatibilities.
Lack of planning for regulatory compliance – Ignoring certification and compliance requirements from the outset can lead to costly redesigns or market failure. Cybersecurity is not an afterthought.
Overconfidence in workarounds – Relying on quick fixes instead of addressing core architectural flaws eventually causes systems to collapse under their own complexity.
Resource misallocation – Either over-engineering trivial aspects or under-investing in critical areas doom a project before it even reaches production.
Leadership and management failures – Poor decision-making, lack of technical oversight, or a reluctance to admit failure result in projects continuing long past their viability.
Turning Dead Horses into Success Stories
Fail early, fix early: The earlier a project acknowledges failure, the easier it is to recover and pivot toward a viable solution. Delaying the inevitable only increases the sunk cost and technical debt. Projects that adapt quickly are more likely to succeed, while those that cling to failing approaches often suffer prolonged and costly setbacks.
Another critical information to consider when issues are detected is where exactly they lie. The lower the impaired layer in the stack, the more critical it is to address it directly. Hardware flaws, in particular, must be resolved at the hardware level. Attempting to patch them in software is a short-term fix that can lead to cascading issues, bloated workarounds, and eventual regret. As the saying goes, “A hardware bug that can be fixed in software is not a software bug.”
When working with hardware, keep in mind:
Don’t respin the hardware too soon – Once a bug is found, implement a temporary fix and continue testing. Ensure all features are validated before committing to a redesign. Premature respins risk missing hidden flaws that could surface later.
Don’t rush the qualification process – A rushed qualification can be an expensive misstep. If issues arise after qualification, the entire process must be repeated, leading to wasted time and resources. Instead, allow room for iteration before committing to final validation. – Rushing to certify a design that may still require changes is a costly mistake. If a respin is inevitable, qualification will have to be repeated, doubling the effort and expense.
Recognizing failure patterns early and making proactive decisions can prevent a project from spiraling out of control. Instead of doubling down on failing approaches, organizations should find the courage to take a step back and reassess their direction. Instead of throwing more resources at a failing initiative, companies should:
- Define clear and stable requirements: Avoid drifting objectives by locking in specifications and resisting unnecessary changes.
- Embrace technological evolution – Stay updated on industry best practices and modern architectures instead of relying on outdated solutions.
- Choose the right hardware from the start – Selecting a well-supported and appropriate platform prevents costly software workarounds.
- Balance agility with long-term planning – Rapid prototyping is important, but transitioning to production requires structured decision-making. Embedded platforms are not made equal, so let your MVP be as close as possible to the production unit and allow iterations.
- Acknowledge failure quickly – Accept when a project is not viable and pivot before investing even more effort into a doomed approach.
- Prioritize reviews at every project stage, from the system level down to the software and hardware components through the V&V procedures and documentation—review, review, review. Periodically reassess the system’s scalability, maintainability, and compliance before issues become irreversible.
- Encourage a failure-tolerant culture – Empower teams to recognize when something isn’t working and advocate for necessary changes.
Reviving the Race: From Setbacks to Success
Embarking on an embedded systems project is a complex journey that demands careful planning, flexibility, and a willingness to acknowledge when things go wrong. The key to avoiding dead-end projects lies in failing fast, learning faster, and addressing issues at their source. Delaying critical decisions or patching over foundational flaws only prolongs the pain and escalates costs. Trimming the hooves goes a long way.
If you find yourself struggling with a project that seems like a “dead horse,” it might be time to bring in a fresh perspective. With decades of experience in embedded systems development, Embedded Expertise specialize in helping teams recover failing projects and set them back on the path to success. Whether it’s an in-depth system review, architectural redesign, or hands-on troubleshooting, we can help you move past the roadblocks and deliver results.
