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 :
- Create constancy of purpose for improving products and services.
- Adopt the new philosophy.
- Cease dependence on inspection to achieve quality.
- End the practice of awarding business on price alone; instead, minimize total cost by working with a single supplier.
- Improve constantly and forever every process for planning, production and service.
- Institute training on the job.
- Adopt and institute leadership.
- Drive out fear.
- Break down barriers between staff areas.
- Eliminate slogans, exhortations and targets for the workforce.
- Eliminate numerical quotas for the workforce and numerical goals for management.
- Remove barriers that rob people of pride of workmanship and eliminate the annual rating or merit system.
- Institute a vigorous program of education and self-improvement for everyone.
- 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 . Conveniently, an official Docker Hub image is available to quickly spin-up and explore this tool . 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 \ Dsonar.login=YOURKEYHERE
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:
- 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 Output||Category||Name|
|Input||Quality Definition||Quality Profiles|
|Output||Project-Level Data||Inspection Coverage|
|Output||Project-Level Data||Code Duplications|
|Output||Project-Level Data||Code Base Size|
|Output||Project-Level Data||Programming Languages|
|Output||Issue-Level Data||Type (Bug, Vulnerability,…)|
|Output||Issue-Level Data||Issue Status|
|Output||Issue-Level Data||Creation Date|
|Output||Issue-Level Data||Programming Language|
|Output||Issue-Level Data||Rule Violated|
|Output||Issue-Level Data||Coding Standard|
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
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.
 W. Edwards Deming’s 14 Points for Total Quality Management. (n.d.). Retrieved from https://asq.org/quality-resources/total-quality-management/deming-points
 SonarQube Docker Hub. (n.d.). Retrieved from [https://hub.docker.com/ /sonarqube](https://hub.docker.com/ /sonarqube)
 GitHub SonarGo: Go Analyzer for SonarQube. (n.d.). Retrieved from https://github.com/SonarSource/sonar-go
 Continuous Inspection SonarQube. (n.d.). Retrieved from https://www.sonarqube.org/