Contents
The quality attributes are important properties of a software. They fulfill salient needs of customers. For example, scalability, usability, resilience, performance. But they are non-functional aspects of a software. No customer comes to you and asks that I need software to increase the performance of my employees. They will ask, I need software that increases productivity of my Human Resource managers. And by the way, the software should be fast, all my 5 thousand HR managers could work at the same time opening multiple windows. The software could be used 24x7x365.
The main requirement is to solve the problems that arise from the day to day tasks of HR employees or to automate some part of their work using software. All the other qualities of the software regarding performance, availability, resilience are hidden expectations. Each quality attribute needs to be addressed as concrete requirements in the architecture document with details to ensure that the software can live up to the customer expectations with regard to quality. The details should include who is the initiating actor or component who will perform a task that will result in the quality attribute scenario to happen. Means the below questions need to be addressed:
Who starts the action?
Which part of the software product will execute the task?
How does the interaction take place?
Under which condition the interaction takes place?
What is the result or response of the activity ?
How do we measure the quality attribute in that scenario?
We should not underestimate the measures for the quality attributes. The architect needs to come up with some measurable KPIs and the unit of each KPI that can quantitatively measure each quality attribute. And how much unit of measures indicate the different levels of quality that has been achieved also need to be benchmarked.
We all know what those quality attributes are and what purpose they solve. If not, I recommend you read about them online. There are many good write ups available in the public domain. In this article I am rather introducing a completely different viewpoint about the quality attributes. I am going to discuss the conflicts they have. It might not be obvious but when we think deeper and try to implement we can see the contradictions that exist among many of the quality attributes.
What are the tradeoffs between software quality attributes ?
There are many quality attributes that oppose each other, meaning if the quality of one attribute is high then we need to compromise on one or more other quality attributes. We should know
How to deal with those tradeoffs
How much weightage to provide to which attribute based on the requirement
How to deal with the changing requirements and boundary conditions
Here are some examples of quality attributes that oppose each other:
Simplicity vs Legacy functionality or reusability
If a functionality can be developed from scratch it will be based on a simple architecture but many times a legacy functionality is chosen to save effort and time. When we try to reuse a functionality in various use cases the implementation needs to be enhanced and has to be made more generic. When we try to implement for greater reusability the architecture becomes more generic and becomes more complex. Sometimes incorporating new functionality into existing functionality reduces maintainability too.
Security vs Usability
When we try to increase security in the workflows and processes, it becomes more complex and the ease of use tends to be reduced. For example, if we increase security of a software from simple username and password based authentication to multi factor authentication. In this scenario either user needs to operate another device to fetch the secure code or another software like email to approve it was him only who is trying to login. If the security of the software is increased even by forcefully invalidating the session every 15 minutes the user has to go through the same login process again. It might be acceptable to the user or might be irritating depending on what purpose the software is serving.
Simplicity vs Extensibility
When we try to extend the capability of a software product or application we add a lot of new use cases along with the core use cases the application supports. Each use case brings new requirements and functionality. This compromises the simplicity of the architecture and also the applications.
Flexibility vs Ease of Maintenance
Flexibility can be in terms of how the application can be operated by the user and also how the application can be deployed in various infrastructures and environments. Flexibility makes the application more complex to develop and maintain. Each infrastructure could have its own norms that need to be followed and the process of deployment also can vary to a large extent. Another example is, when we want the application to be used from desktop as well as mobile device the design and architecture has to consider both use cases. It also makes the code complex and difficult to maintain.
Big Team vs Efficient Development
A big team means the team will probably have all expertise in the team but managing a big team can lead to loss of time and effort on communication and team management, that reduces efficiency of the team.
Simplicity vs Compatibility
When we want to make our product compatible so that it can be integrated with various other products the chances are very high that the product becomes complex to use and the architecture of the product also becomes complex. That makes it even more difficult to develop and maintain.
Quality vs Features
Many times we fight between spending effort and time to adhere to a higher quality for example by reducing bugs or adding new features or integrating with other applications or services to attract different personas.
Quality vs Cost, Time and performance
It is evident that when a lot of quality checks are added in various parts of the product, the performance decreases as more computations need to be made to perform the quality checks. Also, the cost and time to develop the product decreases to ensure higher quality. On the other hand if a product is developed without providing much attention to quality it will be difficult to enforce quality later.
There could be more such contradictions between the quality attributes and the above is not a complete list. The main goal of this article was to introduce the topic to the architects and developers and encourage them to think about this aspect while developing a product or software or application.