Say "No" to MISRA Debts
The notion of technical debt was introduced by Howard G. Cunningham in 1992. It refers to the phenomenon whereby technical decisions are taken to obtain a short-term advantage at the cost of longer-term disadvantage. It is a powerful metaphor because technical debt and financial debt are indeed very similar.
Technical Debt and Financial Debt
Financial debt occurs when you borrow money in order to satisfy a short-term need; you will be fully aware that, when you do so, you will have to pay back the debt with interest, compounded with every delay in the repayment; possibly driving you into hardship in the future.
Technical debt occurs when you take a shortcut to gain a short-term advantage, such as a sort-of-running system. Examples of shortcuts are lack of design, lack of modularization, quick-and-dirty programming. Just as with financial debt, you should be aware that, by taking such shortcuts, you will have incurred a debt that has to be repayed with interest. The interest derives from the fact that any poor technical decisions will slow your progress in the future. If the debt is not repayed quickly (e.g., by immediately doing a proper design, ditching poor code and so on), the interest on the debt will compound: the team will continue to take poor decisions, adapting any new work to fit the earlier poor choices.
This is not to say that technical debt is always a bad thing. For instance, when you need a prototype for demonstration purposes, you do want to take shortcuts. The problem comes if and when someone (typically a marketing department) dreams up the idea that, after all, the prototype is almost the product, not taking into account the fact that the prototype is probably associated with a very large technical debt.
Project Debt and Organizational Debt
The debt metaphor extends to projects and organizations. An example of project debt is when the project does not have the right tools, processes and procedures in place. Think of "we do not have the time to set up a proper CI system, we will test manually", or "we do not have the time to select the right tools, we will do with what we have."
Organizational debt is when the organization does not have the right people in the right positions: someone would have to be moved, trained, fired, or hired. As this is time-consuming and/or painful and/or expensive, the needed actions are not done and so the interest on the debt compounds…
MISRA Debt
How does the notion of debt relate to MISRA?
MISRA technical debt is accumulated when MISRA compliance is delayed, in some extreme cases until the very end of the project. MISRA procrastination may involve extensive reworking, increased testing effort, repeated peer reviews. MISRA violations accumulate in tens or hundreds of thousands and their proper resolution will be difficult, if not impossible, to achieve.
Let us simplify, in an extreme way, for the sake of clarity: if MISRA compliance is undertaken at the very beginning of the project, its brute cost will be 50 units, 35 of these will be given back in the form of less debugging, less reworking and a higher quality product. So the net cost of doing the MISRA compliance work starting at the beginning of the project is 50 - 35 = 15.
Pushing the MISRA compliance work to the end of the project will cost 100 units, the compliance work will have to be rushed (to the point of being possibly counterproductive), it will give nothing in return apart from ticking a box in the contract. Spending 15 instead of 100 is a huge saving.
Moreover, if MISRA compliance is rushed at the end of the project, the delivered software will be of lower quality, possibly leading to problems in the field. In such cases, the cost of this decision will be significantly more than 100, and could be more than 10 times as much.
MISRA project debt is subscribed, e.g., when an inferior MISRA-checking tool is selected, or when it is not deployed in the most effective way for the project at hand, or when a deviation procedure is not put in place at the outset of the project so that developers deal with MISRA violations in inconsistent or uncoordinated ways. By selecting the right tool suite and by strategically involving a MISRA troubleshooter, you can repay this kind of debt quickly.
MISRA organizational debt takes place, e.g., when developers and managers are not suitably trained. An untrained manager will not be able, at the outset of the project, to select the proper tooling, to negotiate the MISRA compliance clauses in the contract with the acquirer and, at the end of the project, to formulate a defensible MISRA compliance statement for the project. Untrained developers may completely misunderstand the MISRA guidelines and act on the code in a counterproductive way.
▶ Check out MISRA Compliance for Project Managers online training course, where managers can learn how to leverage employees and company resources to support and bring out the best in a team with MISRA compliance objectives; as well as how to manage all stages of a project lifetime, as far as MISRA compliance is concerned.
▶ Developers can rely on Effective MISRA C, a 20-hours online course on MISRA C:2012 Revision 1 with Amendment 2, the latest version of the MISRA C standard, which includes the new guidelines for security and preliminary support for C11 and C18. The course is designed to significantly strengthen the skills and competences of teams involved in the design, development and verification of critical embedded software systems.
Summarizing, you have plenty of reasons to say "No" to MISRA debts of all kinds. BUGSENG is your ideal partner on this, as our experts have strong experience in the application of the MISRA coding standards to new as well as existing projects and can support your organization with highly specialized consulting services.
Read a consulting case: how BUGSENG moved the Zephyr Project towards MISRA Compliance.
Tool wise, the ECLAIR Suite can significantly streamline your development process. You can deploy ECLAIR on an integration server to keep your projects under continuous analysis within the most popular DevOps, such as Jenkins, GitLab and GitHub.
With the help of these systems, whenever a change is committed into the source code repository, static analysis is triggered, and developers will have access to the analysis results via the web. You can read more about this in a previous blog and watch a webinar.
Read a customer story: TrustedFirmware chooses ECLAIR for the deployment of static analysis solutions in complex and distributed CI environments.
Register to next ECLAIR Presentation
A monthly introduction to ECLAIR Software Verification Platform held by BUGSENG experts. This is particularly useful to optimize the evaluation process of the tool or even to get you up to speed on the latest features. This presentation is highly interactive and therefore attendance is limited. A final Q&A session also allows attendees to dig deeper into their requirements and curiosities.
Don't forget to join our LinkedIn community to keep up to date with all our news. Also, subscribe to BUGSENG YouTube channel to boost your knowledge of the safe and secure software world. Our videos dive into functional safety, tool qualification, MISRA compliance and so much more.