Low quality is expensive. High quality is cheap. Without quality, product delivery is unsustainable. Many people (mistakenly) believe that high quality is expensive. But actually, poor quality is much more expensive! Poor quality is like an avalanche. At first, it’s small, unnoticeable. But then it accumulates, and we reach a point where we’ve lost control.
Thanks Petula, yes - the exponential explosion of poor quality. Bad code multiples fast.
My experience is that firstly there's pressure to do quick-and-dirty to get to the first release, and then after the first-release the team continues on that low-quality code base, getting slower and slower.
I didn't know about ISO-25010. Thanks! You made my day :)
About quality, my biggest challenge has been the same for several years now. How to make the management understand that internal software quality is important. How to use the numbers and data we have at our disposal to get slack time to work on refactoring, decoupling and code organization. It's hard, imo, to make the product and the management understand that X% of the time should be invested in quality. They prefer devs to fix bugs and release new features.
Thanks Julien! Yes, I didn't know about it either before, I knew about ISO/IEC 9126 and then later found out it was superseded by ISO/IEC 25010. I found it because quite often people are inventing and re-inventing the meaning of quality... or people get stuck in some narrow definition of quality.
One interesting thing is often when developers say quality they might mean just clean code. But here from the above we can see that Functional Suitability is the first item mentioned by the standard - does it work?
The way I see it - external vs internal quality. Some of these quality attributes are above the iceberg, some are below the iceberg. For example, problems in Functional Suitability are visible, problems in Usability are visible.. Problems in Performance Efficiency are sometimes visible sometimes not... Here I mean visible to the end user.
But characteristics like Maintainability are not directly visible to the end user, but they are indirectly visible - through schedule delays and greater costs in the long term.
"It's hard, imo, to make the product and the management understand that X% of the time should be invested in quality. They prefer devs to fix bugs and release new features."
Management sees quality as an additional cost. For example, test automation as an additional cost. But actually test automation cost is a replacement of manual debugging cost...
Regarding your closing questions, I believe the quality issues I have encountered were mainly: Maintainability and Performance.
It was easy to spot Performance issues because the QA Engineers would stress the Product, but solving it was another ball game.
Of course, Maintainability was also a factor in poor performance because sometimes you have legacy code that no one dares to touch, which might be the source of your performance issue.
Now that I think about it, Maintainability was also an issue because the Architecture was neither clear nor Modular enough to be flexible for some changes.
With those qualities in mind, I can now look at my work differently.
"Poor quality is like an avalanche"
I'm totally stealing that line!
Thanks Petula, yes - the exponential explosion of poor quality. Bad code multiples fast.
My experience is that firstly there's pressure to do quick-and-dirty to get to the first release, and then after the first-release the team continues on that low-quality code base, getting slower and slower.
I didn't know about ISO-25010. Thanks! You made my day :)
About quality, my biggest challenge has been the same for several years now. How to make the management understand that internal software quality is important. How to use the numbers and data we have at our disposal to get slack time to work on refactoring, decoupling and code organization. It's hard, imo, to make the product and the management understand that X% of the time should be invested in quality. They prefer devs to fix bugs and release new features.
Thanks Julien! Yes, I didn't know about it either before, I knew about ISO/IEC 9126 and then later found out it was superseded by ISO/IEC 25010. I found it because quite often people are inventing and re-inventing the meaning of quality... or people get stuck in some narrow definition of quality.
One interesting thing is often when developers say quality they might mean just clean code. But here from the above we can see that Functional Suitability is the first item mentioned by the standard - does it work?
The way I see it - external vs internal quality. Some of these quality attributes are above the iceberg, some are below the iceberg. For example, problems in Functional Suitability are visible, problems in Usability are visible.. Problems in Performance Efficiency are sometimes visible sometimes not... Here I mean visible to the end user.
But characteristics like Maintainability are not directly visible to the end user, but they are indirectly visible - through schedule delays and greater costs in the long term.
"It's hard, imo, to make the product and the management understand that X% of the time should be invested in quality. They prefer devs to fix bugs and release new features."
Management sees quality as an additional cost. For example, test automation as an additional cost. But actually test automation cost is a replacement of manual debugging cost...
Thanks for the detailed article!
ISO-25010 was also a discovery for me.
Regarding your closing questions, I believe the quality issues I have encountered were mainly: Maintainability and Performance.
It was easy to spot Performance issues because the QA Engineers would stress the Product, but solving it was another ball game.
Of course, Maintainability was also a factor in poor performance because sometimes you have legacy code that no one dares to touch, which might be the source of your performance issue.
Now that I think about it, Maintainability was also an issue because the Architecture was neither clear nor Modular enough to be flexible for some changes.
With those qualities in mind, I can now look at my work differently.
Thanks!