Quality isn’t a tool–You can’t install it!
Did you ask yourself why a team in an organization produces very good software quality and another team in the same organization just struggles to get things done and those things are in really bad quality? Interesting is also that for both teams exists the same rules (methologies, procedures, tools, frameworks, etc.). But why could and does this happen?
Some people – mostly managers or vendors – try to distill quality to a recipe. Vendors could sell it expensively (with consulting) and managers can buy it to prove their bosses that they didn’t make something wrong (they used the standard procedures and tools). This whole thing is ridiculous, also because it happens again and again (also with agile practices).
So, you can’t buy quality, neither you can install it in your team or organization. Also it isn’t a tool, which makes the quality (many managers think that frameworks guarantee quality, which is completely wrong). But why can one team be so much better than another one? So we are back to my question at the beginning of this blog post.
The only reason for this difference are the people. The people or some of them in the good team care about their profession. So they keep up-to-date (read blogs, articles, books, etc.) and leads other team members to become better. But the one of the most important things is unfortunately discipline. So you have to improve yourself constantly (keep you out of the comfort zone) and look always for improvements for you and your team. And yes, that isn’t easy.
Once you are one of those people, be aware of being dogmatic, just stay pragmatic but insist on the important principles as long your arguments are reasonable.
And the managers? If they are not able to change themselves (especially the middle management), then it’s up to you to change the organization – it’s your career and life.
13 thoughts on “Quality isn’t a tool–You can’t install it!”
I would first start with asking what is quality.
Quality is not absolute. What is better quality a RollsRoyce or a Subaru? You can’t say… for the typical swiss mountain farmer, a Subaru is certainly better quality.
Quality has to be defined by the customer or matched to the customers needs. So who defines quality in the teams you have in mind? Does the team have a common understanding what quality is? Is there a common understanding between the different teams, which supposedly differ in quality? Does the customer also see that big quality difference you are mentioning?
Also you can reach quality by very different means. We as coders usually only see a small fraction of the whole spectrum.
@Jonas
Thank you Jonas for your fast response.
Well I’m speaking here of software quality, more precisely about code quality. Unfortunately this isn’t something a customer see or immediately recognize. And this is also a reason, why managers can get away with short time thinking (‘just hack the code’). For software projects where the software should life the normal cycle (10 years or more), there is quite a common understanding what software (or code) quality should be. There are patterns, anti-patterns, smells, metrics etc. which help you to do a good job (and of course you keep this collection up-to-date).
Software quality and code quality are certainly not equivalent.
My point is, that also code quality is not absolute. It depends on the project. And I believe there is no such thing as a “normal cycle”
Also code quality should only be relevant if it provides value to the customer.
And even then it has to be traded-off against other factors: What are the opportunity costs of code quality? Are there other measures that provide better value for the customer?
There are projects where code quality is just not relevant.
There are customers that just don’t want to pay for code quality.
These are still valid contexts and approaching them with the code-quality-hammer will just make you, your team and the customer unhappy.
And finally: Who defines code quality anyways? Uncle Bob? The pope? The team? The architect? I doubt there is a common understanding… Just start with what is “good-enough quality”?
@Jonas
That’s the point, be pragmatic but insist on principles which are reasonable for your project, software.
Btw, interesting sentence: “Software quality and code quality are certainly not equivalent”. If this is true, from where come the bugs if not from the code? 😉
As this discussion shows, it is pointless to define quality from a dogmatic point of view and introduce it into a project or team. It is important as you showed with your questions and scenarios (which I agree with you), to adapt your experiences, practices to the current project/software and customer. And yes, there are customers who don’t want to pay for software quality – this was something what I had to learn.
@Jonas
Be pragmatic means also ask yourself always if you don’t overengineer the whole thing (opportunity costs, customer needs, relation to the project, relation to the life cycle).
Therefore you need good people, who are able to analyze those contextes and ask those questions and answer them reasonable. This was my point.
There isn’t a recipe, there are just ingredients (patterns, smells, etc.).
I would interpret “software quality” in the sense of “product quality”. In an ideal world this should be directly correlated to “customer value”.
However I agree, in a lot of enterprise projects there is no customer, there are just users (inmates?) that often don’t care. So it’s difficult to define value. But I think it’s presumptuous to assume that we as the producers of software are therefore entitled to define value.
And: Yes, most bugs don’t come from code. That is a fact, i.e. see James Martin, An Information Systems Manifesto
And: “bug free” does not imply good code quality, certainly not in your eyes (I know you 😛 )
And: “bug free” does also not imply good product quality (and it is also not a precondition for providing customer value)
Sure. “Be pragmatic” is the silver bullet in every discussion…
Being pragmatic can also mean that you quit your job and become an ornithologist or a dive-instructor…
@Jonas
Yes, I know there could be bugs not directly in code (for example in the requirements), but I was kidding.
I’m not sure if it is a smart idea to couple software quality so thight to customer value. Does the customer really know what the value is. Does the software engineers? What if the value shift? Do we have to adapt the quality as well? Make the quality worse if the customer value sinks? (That was ironic…)
@Jonas
Jep, I know. But I don’t want to fight to hard here with you, my friend. So I used the word “pragmatic”, but not to provoke you. 😉
@Jonas
I agree with you that the value, which the customer gains out of the software (or customer value) is the base for all other decisions.
But I don’t agree, that there isn’t a customer for enterprise software. Unfortunately is there a mismatch between customer (who pays the softare) and the users (who have to use it). This is one of the reasons, why the “Golf course”-desicion-methophor exists.
Very good discussion! The good coder to me is the one that can identify when to write good software and when just not to write anything at all, because sometimes the requirement become irrelevant given the work to accomplish certain tasks and money comes in the picture.
Interesting topic and discussion — software and code quality should, but not always is on the minds of software stake holders (developers, managers etc.). Often the “immediate revenue” is the driving force.
The notion of quality has so many sides to it that it is indeed very difficult to come up with a single dogmatic definition. In science there is a concept of “adequate”, which means that a solution (e.g. method, model) meets the criteria (e.g. time, precision) for solving a certain problem. So, at the abstract level quality could be defined as a set of criteria, and if software meets them then it is of high quality. Every team/company may have their own set of criteria and means to achieve them.
One of the important criteria in software is “maintainability”, which is directly related to code quality. If the code remains maintainable it most likely suggests its good quality (there are other criteria to consider such as runtime efficiency etc.).
In the end every person has an intuitive understanding of the “quality”, where the depth of that understanding depends on personal and profession traits (e.g. systematic thinking, experience, work ethics). As the post states — have a team of self motivated engineers that strive to improve and love their work, and you’ll get a high quality product.