How to Overcome MISRA C Compliance Resistance and Build Developer Buy-In

For developers measured on feature delivery, this feels like punishment. Suddenly, they’re spending more time justifying their code than writing it.

The natural response is resentment when developers encounter rules that seem divorced from real-world embedded constraints. They begin to question the entire standard’s validity. However, the reality is that many MISRA C rules exist because of real failures, such as buffer overflows that caused ECU crashes, pointer errors that corrupted sensor data, and type conversion bugs that led to vehicle recalls.

The moment developers conclude that MISRA C was created in an ivory tower by people who don’t understand their real-world constraints, you’ve already lost them. At that point, compliance becomes an exercise in appeasement rather than a shared commitment to safety, and no amount of tooling or enforcement will fix that disconnect.

The First 30 Days are Where Most MISRA Implementations Fail

The way you introduce MISRA C to your team determines whether it becomes a constructive part of everyday development or an ongoing source of friction. The most common failure is not taking the process seriously from day one. Teams treat MISRA as a checkbox exercise rather than a fundamental shift in how software is developed, and that mindset sets the tone for everything that follows.

The solution starts before you write a single line of code, when you create a compliance plan with your stakeholders. This means sitting down with your customer (or whoever is mandating MISRA C) and agreeing on which rules are required versus advisory for your specific application.

MISRA C does provide flexibility, whereby some rules are essential for safety; others are contextual good practices. If you skip this categorization phase, you’ll spend months arguing about which rules truly matter for your specific system.

The second major mistake is running MISRA C checks only at the end of a project. We addressed violations as we developed a Bluetooth project, which is why remediation was quick despite the complexity.

When you integrate compliance checking into your daily development workflow, issues stay small and manageable. If you wait until the end, violations accumulate into technical debt that forces risky late-stage changes. The difference between 10% to 15% additional effort (continuous compliance) and 30% to 35% (retrofit) isn’t just timing — it’s the difference between building in quality versus bolting it on afterwards.

Most MISRA C violations occur in memory management. Pointer checks, bounds handling, and allocation rules all prevent buffer overflows, crashes, and security vulnerabilities that can lead to real-world failures. When developers understand that careful memory management is the core safety issue, not an arbitrary restriction, resistance drops.

Excessive compliance can also harm your project just as much as insufficient compliance. Making all advisory rules mandatory unnecessarily restricts developers. When every advisory rule becomes mandatory, developers waste time working around arbitrary constraints instead of solving real problems. This leads to convoluted code without improving safety. For example, blanket bans on go-to statements ignore that go-to has legitimate uses in embedded systems for error handling and resource clean-up.

A thoughtful approach examines each use case rather than applying blanket prohibitions. The key is understanding which rules carry the greatest safety impact for your specific application. In our experience, memory-management rules — specifically accessing memory and checking pointers — consistently matter most.

Building Buy-In

If you’re about to introduce MISRA C to your development team, these are the points that set you up for genuine success:

• Be explicit about the cost: Building MISRA C compliance into development from the start typically adds around 10% to 15% to delivery time. Retrofitting compliance later can add 30% to 35%, even when existing practices are reasonably aligned.
• Explain why compliance is non-negotiable: Tie MISRA C adoption to real, project-specific consequences, such as vehicle recalls, safety failures, security risks, or certification requirements. Make it clear this isn’t about bureaucracy, but about avoiding unacceptable outcomes.
• Define how MISRA will be applied: Agree upfront which rules are required and those that are advisory for your application. MISRA C is deliberately flexible; treating every rule as mandatory wastes effort without improving safety.
• Integrate compliance into daily development: Run MISRA C checks continuously so that violations remain small and manageable, rather than accumulating into late-stage technical debt.
• Handle unavoidable violations pragmatically: For third-party or legacy code you can’t fully control, document justified deviations rather than forcing unsafe or artificial workarounds.
• Keep the focus on safety, not reports: The goal isn’t perfect compliance metrics, but software that behaves predictably and fails safely when the unexpected occurs.

The Tools You Actually Need

One area where teams waste money is over-investing in expensive tools before understanding their actual needs. For development, we primarily use Cppcheck with the MISRA plugin. The free version handles basic checks reasonably well. The premium service costs around £1,800 to £2,000 per project annually, which is far more affordable than automotive-certified tools that can cost tens of thousands.