A Roadmap for Developing Code Quality Maturity in your Organization
Where does your organization stand in terms of software quality maturity? Take a look at TIOBE’s checklist to find out!
Achieving high software quality does not happen overnight. It is a long journey that should be taken step by step. At TIOBE, we defined a set of maturity levels to see where an organization stands in terms of software code quality. By going through this checklist, you can determine what your next step should be, and how to achieve it! For every level in the checklist, TIOBE has specific materials that can help you take the leap to the next level, so feel free to reach out to us if you need any help.
Criterion: Have done one quality measurement of your codebase
Congratulations! You have done your first software code quality measurement! This is where your journey towards higher software quality starts. An ad hoc measurement give you a snapshot of what your code quality is like at a specific moment in time. There can be many reasons why you have performed this measurement: you are close to an important delivery and want to make sure that the reliability of your code is up to the mark. Or you want to spend a large amount of time refactoring, but want to know which parts of your code are the least maintainable before you start. Regardless of the reason, you now have tangible results that you can use to start with improvements to your software.
Criterion: The Majority of your code is automatically checked on quality on a continuous (preferably daily) basis
Now that you’ve made some improvements based on the first measurement, you want to know whether these improvements actually improved quality as a result. Has the refactoring actually improved maintainability? Has our reliability-score increased after solving these bugs?
The best way to make sure that feedback on improvements is quick, is simply by doing a quality measurement on a daily basis. Every day, you can see the results of newly committed code to your overall quality. While the ad hoc measurements help with finding the hotspots that need attention, it is continuous monitoring that allows you to follow up on those hotspots and make improvements.
Criterion: Engineers are actively checking code quality before committing
Once you have implemented continuous monitoring, you have clear insights in how your software quality is evolving over time. And while continuous monitoring helps with finding and then fixing hotspots as described earlier, it does not necessarily prevent new defects from slipping in (it only allows you to spot them as soon as they do).
The next step would be to make sure to involve end-users to such a degree that they are actively trying to prevent creating defects. Of course, engineers are not intentionally introducing defects, but without
the proper tooling, it is difficult for them to prevent this from happening. An example of how this can be tackled is giving engineers the right IDE integrations to already check for metrics like coding standards while they are developing. The faster the feedback for the engineer, the better. This way many defects can be prevented before code is even committed.
Criterion: The majority of your code has to pass through a quality gate, and the code is rejected, this should
block delivery
As stated before, engineers generally want to deliver high-quality software because of their dedication to their craft. However, there are circumstances under which an engineer might want to cut certain corners to, for example, deliver their software on time. While sacrificing quality for delivery speed is something that might be plausible in some situations, it is generally not recommended. Consistent low quality can eventually cost more than delivering late, so as an organization you should try to guard certain minimum criteria for delivery.
This is where quality gates come in: quality gates prevent a delivery from being made if a certain set of thresholds are not met. This is generally a set of criteria the organization as a whole has agreed upon that should never be breached, regardless of release pressure. Some examples of quality gates are that engineers are not allowed to introduce coding standard violations of high severity, or use certain constructs that decrease the reliability of the code. All these things can be checked automatically before an engineer even commits the code, and this ensures that feedback loops to engineers stay as short as possible.
Criterion: You have a quality board within your organization that sets software quality strategies, and discusses
how to execute and improve them
In large organizations, it could be the case that the previous 4 levels were achieved simultaneously in two different business units. However, BU #1 might have decided to quality gate on other metrics or rules than BU #2. This is not a problem (they might have very different application domains), but who is going to decide whether they should check against some homogenous set of rules, or are allowed to decide for themselves what they want to check? And what tools should be used during these checks? And what if we have adopted a coding standard to follow, but want to deviate from a subset of those rules?
In all these cases, it helps to have an organization-wide software quality board that makes decisions on these matters. This board should preferably contain experts in both the programming languages used within the organisation, as well as experts on the internal development process. Having such a board allows for the building up of expertise in software quality governance within the boundaries of the organisation.
Criterion: Software field defects are direct input for your software quality strategy
For this level to be achieved, there should be a direct feedback loop from the field back to the rules you are checking (for example within your quality gates). What does that mean in practice?
A software bug causes a severe system failure at a major customer site. The occurrence is registered by the service team, and send back to the software development organization. There, they see that it was a specific bug that caused it that, which was not caught by a quality gate. The main question that should be asked at that point is: how can we alter the quality gate in such a way, that from now on, all occurrences of this bug will be caught?
This usually means that the software quality board has to come up with and implement some new rule that would have prevented the bug from remaining undetected. Integrate these rules into your quality gate, and there you go: the field defect was input for improvements that lead to a permanent check that prevents this bug from ever occurring again.
Reaching level 6 is a very difficult task to achieve, because it requires effort from the entire organization, not just the business units developing software. Even though reaching level 6 might require a lot of resources, it usually pays itself back quickly due to the lower amount of field defects occurring. This saves times, effort, frustration from customers, and costs. If you need any advice on how to improve the software quality maturity in your organization, feel free to reach out to us: we are more than happy to help you on your way!
Get in touch