Software quality can be tricky to evaluate, some say it is something you only recognize when you see it.
As for quality for development, coming from such a deterministic and scientific-oriented field, it should be fairly easy to assess, right? And yet, quality for a developer might not be the same thing as for a project manager, a tester, or a quality engineer. There are different points of view to look at code quality, and it’s not so straightforward to apply any quality point of view to any stakeholder of the Software production process.
So what quality point of view fits best a developer? And what is quality for a developer?
Code quality points of view
Following the different layers of interests and stakeholders, code quality could be split into these points of view:
- Process point of view
In that case, code quality comes from compliance with development standards. International organizations as MISRA, or consortiums for each industry define such standards to cover safety, security, etc.
A strong requirement here is traceability, as we need to make sure global quality estimation accounts for the quality of each related component of a project. As a consequence, a lesser quality sub-part (a function, a test, a requirement) will impact the global quality assessment.
Ultimately, we ask the question “Are the company guidelines being followed?” - Project point of view
Closer to actual development, code quality at a project level relates to tracking its lifecycle.
For example, we need to check if we are meeting the current milestone quality objectives. Further on, we also need to estimate if we’ll meet the future planned milestones too.
Another concern is to know if we are ready to deliver the product we promised.
This time, the question is “Is the project on track?” - Product point of view
This aspect seems to be the one closest to developers, because it’s related to the metrics and indicators directly computed from the source code.
We’re talking about test coverage pointing to statements and lines of code, or technical debt based on coding rule violations. Code cloning is also a concern at the source code level.
This time the question on our mind is “Is the code good?”
Quality from a software developer’s view
In addition to the point of view analytical approach, we decided to ask our R&D colleagues the very same question “What is quality for a developer?”
We gathered development colleagues from embedded and application fields, asking them two questions:
- What is quality for you?
- What motivation or pain does it generate?
After a couple of hours of brainstorming (and some after-work fun altogether), we came up with several feedbacks, which we then analyzed and regrouped into categories. We even created a nice graph with the data 😊
From this experience, we learned several things:
- Motivation to produce software quality clearly comes from clear and detailed specifications (User Stories must be unambiguous), closely followed by code formatting checks (to ensure normalized naming, and simplify code review), review activities (related to pull requests for example).
- Pains related to quality mainly come from overwhelming notifications (too many automated emails or messaging apps activity drown the useful information), followed by the difficulty to apply good practices consistently (coding practices may differ between developers, and legacy code is sometimes not impacted by certain rule checks)
- Dashboards are not the best fit for development work. Instead, focused reports or summaries would be more suitable:
- A commit analysis would show the quality impact of the latest code modifications
- Targeted notifications would help a developer review the code, tests, and tickets he is responsible for
- Specific code analysis indicators would point to specific code fixes (comments, formatting, good/bad patterns)
- Fix assistance would provide recommendations and examples to solve coding rule violations
In the end, it is not surprising that developers have a clear need for software quality. Increased maintainability alone is a strong argument for that. The most important aspect of quality is that it should seamlessly integrate with development activities.
Providing focused quality reports instead of broad quality indicators, sticking to the development cycle, and avoiding external processes are good ways to integrate quality as part of the development.
