Product quality vs Code quality
Most developers are driven to write good quality code. That drive mostly comes from being a developer who learns to do better every single time.
Some would write super clean code and maintain it like it’s their baby, following best practices and always on a watch in the code reviews to make sure bad code does not creep in.
Some developers are more driven to get the code written out and get the feature working without fussing over the hygiene of their code.
Let’s say, both the coding styles achieve the same goal, a working product. It passes all the acceptance tests on the product. If you are a product owner or a manager or a team lead who is handling this project, what can you say about the code quality?
Can you say one style is better than the other and why? What makes one say that one style has better code quality than the other even when the result is the same product quality? Okay, let’s talk about product quality for a bit and then come back to code quality.
Product Quality
Achieving a level of high quality is the most important motivation for product owners. We know that the code with which the product is built on influences the product quality.
The word “quality” is quite often used loosely. Sometimes, in fact, too loosely. The term quality is very vague. Of course, it depends on the context too. Many use it as an indicative of a standard or high standard. If you say it is a quality product, it is being expressed and understood as a product of high standards.
Quality can also mean: a characteristic of something. This definition of quality is more specific than the former usage.
When speaking about product quality with your team choose to use this definition than the former. Then, you will find that there is a lot more room for questions about the behaviour of the product.
What qualities does your product possess ?
How reliable is the product?
What does reliability mean to the product and its users ?
Someone said the product must be robust. Okay, what does robust mean to our product?
Is complete recovery from failure important or is partial recovery sufficient?
More and more questions.
Be aware that asking these questions can ruffle a few feathers. Because these questions are uncomfortable and it takes some time and effort to answer them. There may be some questions unanswered. And that is okay.
That may be an opportunity to learn more about what the user expects of the product. Or perhaps, even to learn if the product is in line with its vision. One may explore how well the product fits the vision of the company.
If you are a stakeholder in the product, it becomes very important to define what qualities your product must have to deliver a quality product. See what I did there?
An inseparable part of a quality software product is the quality of its code.
Code Quality
To say the code is a quality code, it could generally mean that the code follows the best practices and follows the guidelines recommended by the platform and language of choice.
The code also, importantly serves and caters to the product qualities given that the developer knows about those product qualities. If the developer isn’t aware of the qualities that a product must aim at, then the developer may have to sometimes make assumptions on the qualities.
If you are a developer, have you encountered a situation in a code review when you have received/provided a comment that “a part of the code is an overkill for the feature we are implementing“ ?
How would you navigate those situations?
It’s hard and sometimes, uncomfortable. How would one say a part of code is an overkill. May be there is way to associate that part of the code to a product quality that was intended to be achieved.
If a complete self-healing recovery is one of the qualities your product must have, then it is possible that the overkill is justified. Or not, if your product need not have that quality and a simple recovery may suffice.
There may be harder questions and tougher conversations that the team may have to navigate. Conversations like this can bring better understanding of the product to all of them involved, even the product management. Especially the product management. These conversations are an opportunity to shape the product to its best version.
Do you have to finish the tough conversation before you ship the feature?
No, you don’t have to.
If a developer uncovered something that has not been articulated before, ship your code and make sure all your tests pass. The current state of the product has been feature-incremented.
The tougher conversation can still continue with the team, with your product owner. Once the conversation is complete, note it could either take minutes or hours or even days, then come back to the code to accommodate that change.
The qualities of the product can be broken down to features to be implemented by the development team.
We know how the code affects the product quality. This makes it so important to have tests that verify that the product behave in an expected way every time the code changes. Tests act as a safety net to catch any unintended behaviours.
Not many people see this, but the code that makes your product that you are developing is also your product.
It’s the product of all your engineering and analysis and effort that had to be spent to achieve and arrive at that code. This code represents your product.
The code heavily influences the behaviour of the product. So it becomes important to maintain the health of the code to maintain the product. This will define how quickly the code can be changed to respond to change in the market to keep the product appealing to the users.
Code is malleable in its nature.
But, bad code can be brittle. Brittle code makes it terribly hard to add new features or fix certain bugs. The developer then must resort to apply “ Band-Aid” code. This becomes more and more a liability as time grows. The technical debt starts to mount.
At some point, somebody needs to start paying the technical debt. It better be the product development team rather than the users.
How does the development team have a minimal technical debt?
How would they start minimizing the technical debt they owe?
The authors of the popular book The Pragmatic Programmer drew the analogy of software development to gardening. I love that analogy and find that its a better fit for software practices.
If one has to keep up with the product needs, then one must keep up with its code health too. Like gardening you need the right tools to measure and improve your code health.
If you have not used a static code analyser, the right time to start using it is now.
No matter what your preferred programming language is, you will find a tool to help you with your code quality. I am a dotnet developer and one such tool that I find useful is ndepend. I would be interested to know what tools you use with your platform and programming language, so please feel free to put it in the comments. Others looking to find the right tool may find it helpful.
Once you start measuring your code quality, you know where to focus on when you begin to tackle technical debt. For example, you may want to deal with the code security issues to begin with.
To be agile, remember to measure every time the code changes. It is efficient when the code analysis happen at developer’s computer while coding as well as in the continuous integration.
It is clear that code quality influences product quality. In a software development team, it is favourable to treat the code as an inseparable part of the product.
If one realises that the product is actually a dyad of its code and the product itself, then treatment to the quality becomes wholesome.
Hope you enjoyed reading this.
Until next time. Cheers.
