# Continuous Code Inspections

In manufacturing, the philosophies of W. Edwards Deming drive the quality organization. Deming’s 14 Points on Quality Management serve as the underpinnings for this philosophy. These include [1]:

1. Create constancy of purpose for improving products and services.
3. Cease dependence on inspection to achieve quality.
4. End the practice of awarding business on price alone; instead, minimize total cost by working with a single supplier.
5. Improve constantly and forever every process for planning, production and service.
6. Institute training on the job.
8. Drive out fear.
9. Break down barriers between staff areas.
10. Eliminate slogans, exhortations and targets for the workforce.
11. Eliminate numerical quotas for the workforce and numerical goals for management.
12. Remove barriers that rob people of pride of workmanship and eliminate the annual rating or merit system.
13. Institute a vigorous program of education and self-improvement for everyone.
14. Put everybody in the company to work accomplishing the transformation.

Leading software organizations often look to the manufacturing world for insights on possible innovations and process improvements. For example, lean principles were borrowed from the manufacturing realm. We can look to W. Edwards Deming’s work in quality management for insights on how to improve the software development process. Of particular interest in his 14 points is “cease dependence on inspection to achieve quality.”

While this principle carries a different meaning and motivation in the manufacturing realm, we can consider this principle within the context of software development. Here, the principle is perhaps better implemented as “avoid costly inspection processes that do not address the root cause of poor code quality.” On the cost side, inspection costs should be minimized by using continuous integration processes, such as automated code inspections and automated tests. On the value side, feedback from code inspections needs to make it back to the developer and other stakeholders who have control over the root cause of the poor code quality. Automated, continuous inspection processes, which are integrated with ticketing systems and other feedback mechanisms, provide a low-cost, high-value stage to the software development process.

Consider a tool like SonarQube. SonarQube, a SonarSource product, “the leading product for continuous code quality,” can be used to automatically analyze code for code smells, bugs, and vulnerabilities [4]. Conveniently, an official Docker Hub image is available to quickly spin-up and explore this tool [2]. Run the following command to get a localhost instance running:

docker run -d --name sonarqube -p 9000:9000 sonarqube


After setting up a project, you’ll need to run a scan for some sample data. Install the SonarQube CLI, then run the following after navigating to a project source code directory:

sonar-scanner \
Dsonar.projectKey=test \
Dsonar.sources=. \
Dsonar.host.url=http://localhost:9000 \


Upon opening the webpage, the user is presented with a clean, friendly interface. Exploring the interface, we note that the continuous inspections can only be ran against source code. Supported languages include Java, VB.NEAT, C/C++, PL/SQL, C#, T-SQL, COBOL, Flex, ABAP, Python, HTML, Groovy, RPG, PHP, JavaScript, Swift, TypeScript, Visual Basic, Objective C, PL/I, and XML. While it’s not obvious from the landing page, other languages are officially supported, such as Golang [3]. A robust API for the tool greatly improves extensibility and automation options. Given the tool’s emphasis on inspecting for bugs, vulnerabilities, and code smells, it makes sense that more qualitative work products like requirements documents are not supported.

Figure 1: SonarQube Landing Page

With this technically-focused, automation tool, some staples of code review are not supported. For example,

SonarQube does not have:

• Checklists
• Document reviews
• Discussion mechanisms

Rather, SonarQube works best when alongside another code review process, such as manual pull request reviews in GitHub for source code and Microsoft Word’s Track Changes for document-type work products.

Inspections in SonarQube have a variety of inputs and outputs. Based on the instance configuration, inputs and outputs can be automated - for example, automated quality gates based on the “security” results from the last inspection. Some of the inputs and outputs for the inspection system include:

Input or OutputCategoryName
InputInspection ApproachRules
InputQuality DefinitionQuality Profiles
InputQuality DefinitionGate
OutputProject-Level DataReliability
OutputProject-Level DataSecurity
OutputProject-Level DataMaintainability
OutputProject-Level DataInspection Coverage
OutputProject-Level DataCode Duplications
OutputProject-Level DataCode Base Size
OutputProject-Level DataProgramming Languages
OutputIssue-Level DataType (Bug, Vulnerability,…)
OutputIssue-Level DataSeverity
OutputIssue-Level DataResolution
OutputIssue-Level DataIssue Status
OutputIssue-Level DataCreation Date
OutputIssue-Level DataProgramming Language
OutputIssue-Level DataRule Violated
OutputIssue-Level DataCoding Standard
OutputIssue-Level DataAssignee
OutputIssue-Level DataAuthor

Screenshots are provided below to provide the reader with some insight into using the tool, without having to actually spin it up and test it. Note that the example data is just a single scan of a single project repository.

Figure 2: SonarQube Projects Interface

Figure 3: SonarQube Issues Interface

Figure 4: SonarQube Rules Interface

Figure 5: SonarQube Quality Pro les Interface

Figure 6: SonarQube Quality Gates Interface

Final Thoughts

SonarQube is a great example of the new approach to software inspections. By minimizing costs and maximizing value, continuous inspection systems can facilitate excellent quality and a learning organization. As release frequencies continue to increase, industry-wide, there will be a strong need for organizations to adopt advanced tools and automated systems to improve their software delivery process. The organizations leading the industry will need to reach even further (perhaps into other disciplines, like manufacturing), to pioneer the philosophies, processes, and tools of tomorrow.

References

[1] W. Edwards Deming’s 14 Points for Total Quality Management. (n.d.). Retrieved from https://asq.org/quality-resources/total-quality-management/deming-points