#CodeQuality: a definition unknown or misunderstood by most, that goes beyond #SoftwareCraftsmanship.
Given that software is eating the world and IT *is* becoming the business, it do matters.
This post gives a pragmatic definition valuable and meaningful for both IT and the business.
if you were spending your own money to pay software engineers for improving the quality of service/product’s codebase, what would you rather have?
I’ve seen software developers arguing passionately and endlessly about trivial topics such as spaces vs tabs (coding style standards) without coming to a useful conclusion. Code quality is a very controversial topic indeed, but I’m sure you won’t pay for those arguments!
Nonetheless, in a quite useful turn of events, in the last 15 years the agile movement contributed enormously to expand the understanding of quality in IT.
Now our quest for quality can count on patterns (PoEAA, GoF, GRASP, etc), principles (SOLID, Demeter, Simple Design Rules, etc), heuristics of good and bad design (loose coupling, high cohesion, rigidity, fragility, etc), diagnostics (metrics such as cyclomatic complexity, Sandi Metz’s TRUE , etc), and practices (described in the previous post
On the other hand, that understanding expanded so quickly, that the vast majority of the industry has not caught up yet. Most are still at the imitation phase.
Indeed, even in recent years, I’ve seen some business people systematically cutting down quality up to a point of bringing the project or product to its knees, and I’ve seen some technical people asking for time and resources to improve quality and then failing to produce the promised benefits. I’m sure you can also recall some epic IT failures from the news. You would not want that either, for your money.
Mastering those patterns, principles, heuristics, diagnostics, and practices – software craftsmanship – is the best way we know today to pursue the quality in the code. But it is not the whole answer! They all are a means to an end.
What is the end goal of code quality, what is the meaning of code quality for the business?
Here are few examples of end goals of code quality that support key tangible and beneficial business needs/wants:
- Product’s reliability
to avoid service interruptions, increased costs, and reputation damage; and finally to keep users and customers happy
to ever changing users’ needs
to acquire and support new users and to expand in new markets
- Speed & low cost of Change
in implementing the required changes and evolutions
that leads to competitive market prices and lower cost of clients acquisition
- Flexibility & Reversibility
to support options that enable strategic business decisions.
This is the code quality that matters to the business as well as to IT. But how to achieve such quality?
When one blindly applies those quality patterns, principles, heuristics, diagnostics, and practices – that is what I call code quality cargo cult – it doesn’t work.
This is because practices are contextual. Principles, heuristics and diagnostics are broad and blind, abstract, and generic. Quality is elusive, subjective, relative, at times intangible, and it is in constant evolution, always changing in unpredictable ways.
To achieve the quality that enables exactly the business goals needed for the specific product/service, for its users and clients served, for value to be created, and for the current circumstances, one has to select and apply those quality practices in context, each one with the right dosage and the right timing.
The way to do this, is to try to improve the code quality in the best way we know today, measure the impact on business goals, learn what’s working and what’s not, and loop again.
That is the quality that’s valuable and meaningful for both IT and the business!
Thanks to Paul Eastabrook, Praveen Karadiguddi, and Uberto Barbini for their useful feedback and comments.