Code quality and measuring what matters
Quality shouldn’t be in the eye of the beholder.
Chronometer (source: Pixabay)
Do you ever feel like you could and should be writing better code, but not quite sure how to tell if you’re doing your best? You’re not alone.
Vying deadlines and cost concerns take precedence in the world of software, so much so that most developers do not evaluate their source code, according to Gijs Wijnholds, a consultant with Software Improvement Group (SIG), even though most of them think it’s important to do so. We wanted to find out more about this issue, so SIG and O’Reilly partnered to conduct a poll to see exactly what is what and how we could give you the techniques and tools to make this an integral and worthwhile part of your process.
Learn faster. Dig deeper. See farther.
We surveyed working software developers on what makes great quality code and, equally important, how to quantify it. 90% of respondents agreed that “a practical and measurable standard on code quality will help towards improving a software system.” But when it came to questions of what to measure or whether they were actually doing it, the results were more mixed.
Specifically, more than 70% of poll respondents said they apply some form of quality standards, but only half of them check for source code metrics. “This means that around only one-third of the developers perform metrics-based evaluations of their source code, even though more than two-thirds of them think a measurable quality standard would help them achieve better software, so there is definitely room for improvement there,” concludes Wijnholds.
What constitutes software quality?
To be effective, metrics must measure properties that have the most positive impact. According to our poll, 70% of respondents believe that maintainability is the most important aspect of code to measure, even as compared to performance or security.
SIG has found a number of ways to measure software maintainability. In the new book Building Maintainable Software, Joost Visser (Head of Research) and other team members at SIG present 10 principles for maximizing maintainability, including the following:
- Limiting the length and complexity of code units
- Keeping class sizes and unit interfaces small
- Keeping the codebase small
- Automating tests
In terms of measuring maintainability, however, SIG recommends that software engineers focus on “metrics-based evaluations of their source code.” You can check these metrics directly in the IDE using a plug-in like CheckStyle (in Eclipse) or StyleCop (in Visual Studio), or a metrics dashboard like SonarQube.
What do you want to measure?
72% of those surveyed agreed that quality standards should focus on architecture in addition to the coding principles. When it comes to actual measurements, however, developers tend to emphasize source code formatting and design guidelines.
When it comes to maintainability, the most important—and measurable—architecture principles are:
- Separating individual functionalities into smaller, loosely coupled modules (methods or classes).
- Hiding implementation details in a high-level interface.
- Keeping to a manageable number of high-level architecture components.
If measuring is so important, why isn’t everybody doing it?
Our poll indicated that there’s a lack of consensus within software teams about what software quality means. Also, many of our respondents reported that their team leaders don’t support any existing quality standards or consider them a priority. SIG’s 15 years of work in the field confirms that confusion over quality standards or a lack of urgency about looking at them are the main reasons for not monitoring those standards.
Why go to the trouble of checking code metrics?
Measuring the size of code units, checking for duplicated code, and even worrying about the number of high-level components your architecture has may sound like more trouble than it’s worth. The bottom line is, taking steps to write clean, easily maintainable code means less time and money spent fixing bugs and troubleshooting bloated, error-prone code over the long term.
Note
For more, listen to a podcast with SIG’s Head of Research Joost Visser.
To read more about SIG’s systematic approach to implementing and measuring maintainability, get your free copy of Building Maintainable Software, compliments of SIG.
Here are some of the questions in our poll:
- Do you think a practical and measurable standard on code quality will help toward improving a software system?” 315 of 350 answered Yes.
- In your development team, are there any software quality standards that developers have to use? 255 of 375 respondents said Yes.
- Which of the following does the quality standard you use address? 126 of 232 respondents reported checking for source code metrics.
- Which non-functional quality properties for system development is of the highest priority to you? 236 of 345 respondents chose Maintainability.
- What should be the focus of a quality standard according to you? 252 of 348 answered “Architecture and coding principles” or “Architecture principles.”
- What are the reasons for not using software quality standards? The top three answers were “Lack of consensus on what software quality is / which standard to use,” “Currently has no priority,” “Lack of management support.”
This post is a collaboration between O’Reilly and Software Improvement Group (SIG). See our statement of editorial independence.