Intentional qualities
When we work on a piece of software, being it an application or a library, we often focus on its functional requirements. They are usually quite easy to directly observe and test; functional requirements are featured in software marketing materials in the form of “feature matrix” that compares different products. Yet, many non-functional aspects of software, also known as quality attributes or qualities for short, such as reliability, efficiency, security, maintainability, usability, etc¹ can be important, too. They are not as easy to measure, though.
Consider, for a example, a task of picking a library to parse some data interchange format. When you face a problem like this, you might have in mind some specific requirements like “it should be able to parse this and that file we have”. You can quickly sketch test code to vet the candidates you’ve found. It is even simpler if the format is formally defined in some standard or standard-like written document. You’ll just read documentation to confirm that the library claims conformance with the corresponding standard and then all you need to do is to perform a straightforward acceptance test. Trust, but verify.
But what happens if you want to find a fast parser, for example, or if you have some other quality attribute in mind that shall be satisfied to suit your needs? Measuring qualities is way more complicated and quite a non-trivial endeavor. Even simple things, like speed, being it either response time or bandwidth, need a proper test setup and a lot of skill. It is time consuming.
In the past I used to spend a lot of time when faced with a problem like that. You are lucky if you can find a ready-to-use quality comparison in your domain, but more often than not, all kinds of comparisons for non-functional requirements that you can find on the internet are of a very low quality (pun intended). However, over time I’ve discovered a shortcut.
See, the fact is that you cannot accidentally write a software that has a specific quality. You cannot accidentally write fast code. Your code cannot be secure by an accident. Accidentally easy to learn? Never heard of it.
Qualities are often lost by an accident, but are never accidentally acquired. It is similar to the second law of thermodynamics. In order to maintain quality you have to be very conscious, intentional about it. You have to constantly fight against losing it. What’s more, it requires spelling out the corresponding quality as your explicit goal when you start working on a piece of software and careful prioritization of qualities, since different qualities tend to conflict. Try writing something that’s very fast, yet maintainable to see how it happens.
So, the shortcut I’ve found is this. If a project documentation does not explicitly list or tout a particular quality, then it is unlikely to have one by accident. For example, if I’m really looking for a fast parser, then I’ll be looking for project that had an explicit goal to write one. I can save time testing others that did not have such goal. That’s it. Qualities are intentional.
¹ Wikipedia has a separate page that lists various quality attributes, but different sources place emphasis on different aspects of this space.
