How to Stop Developers from Writing Low-Quality Code

Developers tend to go for getting things working, ending up with a working program, lacking the quality you would like to see. In this article I will explain how to get quality code as well.

Quality software is not only software that is doing what it should do. Next to the functionality, a maybe even larger amount of non-functional requirements determine the quality of software.

The ISO/IEC 25010 software quality model describes performance, compatibility, portability, usability, reliability, security and maintainability as additional aspects of software quality (1). But assuring the required quality in all of these aspects appears to be hard when finishing the last few lines of code of the new feature at the end of a long working day.

The result of low-quality software can be performance issues, increased maintenance cost, bugs, difficulty in changing the software and security vulnerabilities. These are all things you would rather avoid, but that requires building good quality software. So, despite high workload and despite the urge to finish that new feature today, we do not want anyone to write low-quality code. How to stop a developer from doing that?

The only way to stop a developer is to break the build!

Every time new code is written and added to the program, the build pipeline is running, a practice known as continuous integration (2).

The build pipeline builds the program and runs various checks to see if the program is behaving according to the requirements. If something is wrong, the build pipeline will stop and report about the problem, which is referred to as a broken build. The problem will have to be fixed first to get to a successful build. 

So if we want to stop a developer from writing low quality code, we must make sure the build breaks as soon as low quality code is added.

Therefore, we add build-breaking checks (build-breakers), to the build pipeline that checks the quality of the code added to the program.

Examples of these checks are:

• static application security tests (SAST), which examine the programming code for security issues
• static code analysis, which checks for coding style and coding issues
• dynamic application security tests (DAST), which examine the running program for security issues
• unit tests, which automatically perform small tests on the program
• fuzzing tests, which send random input to the program and check for unwanted behaviour
• performance tests and end-to-end tests, which test the program as a whole.

OWASP features an extensive list of security tools (3) useful for checking software quality. Most of these can easily be added to a build pipeline. If you want some examples of how to integrate these tools in a build environment, feel free to check out the code repository of the company I work at (4).

We added specific quality checking docker containers as build-breakers in our Google Cloud Build to make sure we build quality in. The screenshot below shows a broken build because the SAST scanner found some issues.

Considering all of this, good software quality is imposed by adding build-breakers to the pipeline. The more you break in the pipeline, the less you break in production.

Lead image by Joëlle van Veen

References

1. https://iso25000.com/index.php/en/iso-25000-standards/iso-25010, retrieved 23 October 2020
2. https://martinfowler.com/articles/continuousIntegration.html, retrieved 23 October 2020
3. https://owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools, retrieved 23 October 2020
4. https://github.com/vwt-digital?q=cloudbuilder, retrieved 23 October 2020