How to reach the Software Quality Graal?

Lately I was asked how many bugs and smells detected through SonarQube were acceptable for a software product. And a Scrum master inquired which organizational changes are necessary to empower software developers to write good code. Speechless and dumbfounded I was unable to answer these questions.

After quite some time I realized these persons believe tools can measure the quality of software. But tools can only measure non-quality.

They tell you when you are doing it wrong, only your heart can tell you when you are doing it right.

But first that does it means to have a quality software product?

A high quality software product has no catastrophic failures, and seldom bad behavior. 

It is maintainable and extendable with new technologies and new features.

The first part is called extrinsic quality and is why customers buy your product. The second part is called intrinsic quality and is why customers buy your product again and recommend it.

Criteria such as test code coverage, static analyzers, coding guidelines are just tools to detect missing quality. They help your team produce higher quality and nothing else. 

I encounter organizations stating that zero defects as measured with SonarQube is the ultimate goal - and they find normal to have hundred of thousands of smells -. Time for a reality check. 

Tools such as SonarQube, unit test coverage are just instruments to support your teams to detect known non-quality.

How to find the Quality Graal?

Below I provide a set of established, old techniques to eliminate non-quality. Most of them are around for at least twenty years. I encourage you to extend your practices with additional procedures based on your measurements and findings.

Extrinsic Quality - Product Quality

Is why you buy a specific car

• Acceptance criteria and behavior test driven development ATDD - You insure through automatic tests the feature behave how your customer requested,
• Defect driven development - You insure through automatic tests your customer will never encounter this exact error again,
• Fast release and deployment cycle - You give your customer a way to detect bad behavior early and have an opportunity to ask for improvement. By fast we mean daily or perhaps weekly.

Intrinsic Quality - Technical Quality

Is why you can daily drive your car and not have to weekly repair it - and later be able to add a charger for your mobile phone without spending a fortune -

• Static code analysis - Known weaknesses are removed from your source code,
• Test driven development TDD - You can change the code without changing the behavior or outputs, see also ATDD,
• Clean code - You guarantee the source code is maintainable,
• Clean architecture and domain driven development - You guarantee the product is extendable.

Accountability

The Scrum Team - Development Team, Product Owner and Scrum Master - are responsible and accountable for the intrinsic and extrinsic quality of the delivered products. Therefore insufficient quality is always a collective failure. 

And truly if the intrinsic quality of the source code is low, it is undeniably a failure. A failure of the development team and of each software developer writing the code; and a failure of the Scrum master holding and teaching agile and Scrum values. 

When there is high pressure on delivery people have a tendency to pay less attention to processes and standards. That is one of the reasons why in Scrum we have the role of Scrum master responsible for understanding and enacting agile practices and rules. 

And no physician will ever cut corners just because he is in a stressful situation. So please be a professional and read again the principles of the agile manifesto such as

Continuous attention to technical excellence and good design enhances agility

Developers please read the seminal book "Clean Coder" from Robert Martin. As a professional you are responsible and accountable for the quality of the software you produce. 

I find intolerable to hear software professionals stating they are not in charge of the intrinsic quality of the product they write. They cowardly try to push the responsibility to the internal quality assurance department or to the whole organization.

The above ideas are keys for Software Craftsmanship.

Kaizen - Small Steps bring First Successes

The first steps to improve your product are quite simple are around for at least twenty years.

• Eliminate all compiler errors and warnings,
• Use static checkers,
• Activate the checkers of the IDE you are working with. For example I am using IntelliJ IDEA and they have extensive checkers,
• If using SonarQube, download SonarLint plugin and simply use it - This tool is best of breed, do not argument and just use it -,
• Write tests with JUnit5, Mockito, AssertJ, Cucumber.

I am ashamed to see software developers not implementing the above measures on a daily basis. I despair encountering Scrum masters who tolerate the situation. These techniques cost nothing, are installed in a few minutes and support incremental improvement of your source code. See also "Why software developers do not need to ask for permission or forgiveness".

Your goal is simply zero warnings at the end of the spring. Later tighten it to zero warnings in the trunk of your git repository. Just do it - and stop arguing about the merits and costs -!

And if you do not agree with one of the warnings just disable the rule and document the reason in an architecture design record ADR.

Agile and Scrum are all about learning and continuous improvement. Please stop talking about quality and just start improving it! I do not want to hear any lame excuses why a software developer is not continuously doing the above activities. 

I acknowledge I am emotionally involved and not fully objective. Lately I saw Java code of three different commercial products and I am still recovering from the missing quality.