After learning what quality is and how to measure it, the final concept we are going to address is the concept of why. That is, why is measuring the internal quality of software important? Moreover, what are the consequences of building low-quality software?
Importance of Measuring Internal Quality
Assuming you are not building a prototype or participating in a hackathon, then it is likely that the software you are developing will evolve and require maintenance. Additionally, it is likely that the developers who will maintain your system are not the same ones who built it. Therefore, to make the source code of your software more reusable, understandable, and maintainable, it is essential for it to have an acceptable level of internal quality. And how do you ensure that the source code has an acceptable level of internal quality?... You measure its internal quality and why do you measure its quality?... Because you cannot improve what you do not measure.
Therefore, if you want to make your source code to be more reusable, understandable, and maintainable, you have to start by improving its internal quality. That is why measuring the internal quality of software is essential. The questions now is, what are the consequences of building low-quality software
Consequences of Building Software with low internal quality
The aspect of maintainability, reusability, and readability are closely related to each other. As a result, systems that are hard to read are typically also hard to maintain and not highly reusable. For example, if your system has a highly coupled architecture, it will be hard for developers to add new features or make changes to existing features. Worst case scenario, making a change in one module affects a significant number of other modules.
From a readability perspective, an architecture that is highly coupled and not cohesive tends to be more complex. Such complexity makes it harder for developers to understand and therefore maintain the system. From a reusability perspective, a highly coupled system with low cohesion in its components will result in a system that is hard to reuse. In turn, resulting in more development time and higher costs.
To avoid costly and time-consuming maintenance nightmares, it is essential to ensure that the coupling between the modules of your system is low and that your modules are highly cohesive. Measuring internal quality attributes such as fan-in, fan-out, and CK metrics such as coupling between objects and response for call are some of the metrics that will help you determine how coupled, and cohesive your modules are and therefore make the appropriate refactoring to improve it.
You cannot improve what you do not measure. The first step towards the improvement of your source code it to measure its internal quality. Measuring internal quality as your system evolves will allow you to identify its weak points and take appropriate action. Start by discussing with your team what attributes of your source code you want to improve or focus on; i.e., complexity, coupling, cohesion, etc. and find tools that allow you to measure those attributes. Finally, use the information obtained from your tools to make appropriate refactoring decision and thus improve the quality of your software.
With this post, we conclude the three-part series of The What, How, and Why of Software Quality. If you enjoyed this article, please recommend and share. Don't forget to subscribe and follow me on Twitter to stay up-to-date with my latest posts. See you on the next series.
How would you rate this article?