How to Reach the Software Quality Graal?

Tags:
2018 06 01 head

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 some time, I realized these people 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, what does it mean 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 it normal to have 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

Ig is why you buy a specific car.

  • Acceptance criteria and behavior test-driven development ATDD – You ensure through automatic tests that the feature behaves how your customer requested.

  • Defect driven development – You ensure 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

It 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 [1, 2].

  • Clean architecture and domain driven development - You guarantee the product is extendable [3, 4, 5].

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 [6, 7]. Insufficient quality is always a collective failure.

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 tend 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 enhance agility.

— Agile Manifesto

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

I find it 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 to 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 [8].

  • 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. They have extensive checkers.

  • If using SonarQube, download link:../../2018/blog-2018-05-01]SonarLint plugin and use it. This tool is the best of breed, do not argument and 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 of 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 for an architecture design record ADR.

Agile and Scrum are all about learning and continuous improvement. Please stop talking about quality. 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 a Java code of three different commercial products. I am still recovering from the missing quality.

References

[1] R. C. Martin, Clean Code. Prentice Hall, 2009 [Online]. Available: https://www.amazon.com/dp/0132350882

[2] R. C. Martin, The Clean Coder. Prentice Hall, 2011 [Online]. Available: https://www.amazon.com/dp/0137081073

[3] R. C. Martin, Clean Architecture. Pearson, 2017 [Online]. Available: https://www.amazon.com/dp/0134494164

[4] E. Evans, Domain-driven design. Addison-Wesley, 2004 [Online]. Available: https://www.amazon.com/dp/0321125215

[5] V. Vernon, Implementing Domain driven Design. Addison-Wesley Professional, 2012 [Online]. Available: https://www.amazon.com/dp/B00BCLEBN8

[6] R. C. Martin, Clean Agile. Prentice Hall, 2020 [Online]. Available: https://www.amazon.com/dp/0135781868

[7] M. Cohn, Succeeding with agile. Addison-Wesley, 2010 [Online]. Available: https://www.amazon.com/dp/0321579364

[8] D. Thomas and A. Hunt, The Pragmatic Programmer - 20th Anniversary Edition, Second. Addison Wesley, 2020 [Online]. Available: https://www.amazon.com/dp/0135957052