“Quality software.” It means something different to everyone who hears it.
In perfume, we can discover and describe our preferences using the Fragrance Wheel. This is a spectrum of scent categories, providing a vocabulary for describing each perfume, the attributes of a scent.
Perhaps a similar construction could help with software quality?
When a developer talks about quality, we often mean code consistency and readability, plus automated testing. A tester means lack of bugs. A designer means a great UI, a user means great experience and exactly the right features and lack of errors or waiting. An analyst means insightful reporting and the right integrations, a system administrator means low CPU usage and consistent uptime and informative logging. Our partners mean well-documented, discoverable APIs and testing tools.
Each of these are attributes of quality. For any given software system and for each component, different quality attributes matter most. What’s more, some aspects of quality compliment each other, each makes the other easier – for instance, a good design facilitates a great user experience. Readable code facilitates lack of bugs. Consistent uptime facilitates lack of waiting. Beautiful (consistent, modular, readable) code facilitates all the externally-visible aspects of quality.
However, other aspects of quality are in conflict. Quantity of features hurts code readability. More integrations leads to more error messages. Logging can increase response time.
If we add nuance to our vocabulary, we can discuss quality with more detail, less ambiguity. We can decide which attributes are essential to our software system, and to each piece of our system. Make the tradeoffs explicit, and allocate time and attention to carefully chosen quality attributes. This gets our system closer to something even greater: usefulness.
The quality wheel pictured above is oversimplified; it’s designed to parallel the original version of the Fragrance Wheel. I have a lot more quality attributes in mind. I’d love to have definitions of each piece, along with Chinese-Zodiac-style “compatible with/poor match” analysis. If this concept seems useful to you, please contribute your opinions in the comments, and we can expand this together.
Sounds good to me. A big part of development is making compromises and explaining those to other people and some kind of visualization would definitely help there.
Excellent piece..One thing which comes to my mind is the cost of this quality ( which might be the cost of very highly skilled developers or personal time/work life balance)
Excellent visualisation for expressing the beauty of code, I do have a question though. How could we visualize risk mitigation in this model?When we move our quality towards a more beautify state (towards the center of the wheel) it effects all other aspects.Love the diagram
More of this please. Love with approach to different aspects of quality, given conflicting perspectives.
More of this please. Love with approach to different aspects of quality, given conflicting perspectives.
It's good to see you writing so much! I have one comment here, though. It is theoretically 🙂 possible to create code that satisfies all the attributes you name, and everyone would be happy then, right? These qualities are hard to achieve at once, but they are not contradictory and do not necessarily clash with one another. But if you create a perfume with all the attributes from that wheel… I do not want to imagine this! So this analogy does not seem perfect to me.
I think that the attributes are in conflict like the author wrote, e.g. \”Quantity of features hurts code readability.\” In fact, imho this is the most important thing in this method because it would make those compromises visible. As in elegant and flexible code vs. simple and maintainable yet rigid code, or bloated, non-intuitive yet quick to use UI vs. simple, discoverable but inefficient UI.
Have you considered using a radar chart rather than a wheel? this way you could model that certain attributes are mutually exclusive.