The goal of a software product is to fulfill certain business needs through a software product. This involves both “building the right thing” and “building it right”. Building the right thing is about understanding the business problems and providing a solution to that. This is known as external quality. It’s about functionalities. Aside from that, there is also the aspect of building it right, which is about internal structural quality and following best practices. It’s about the underlying architecture and design.
At the beginning of the product life cycle, only external quality is “visible” to the customers and users. It’s about whether the functional requirements were satisfied or not, is the user able to achieve what they were supposed to achieve. End users can only see the functionalities and the bugs. They can’t see the underlying architecture nor the code, they can’t tell if the software has high or low internal quality. But the architecture is the invisible frame holding it all up.
However, internal quality becomes more visible during code modifications, whether it’s for new functionalities or bugs, because in either case they read the existing code, understand the existing code. If the software is well structured and follows best practices, then there’s much less time needed to read the code and to implement a new functionality, change an existing functionality, or solve bugs. This means that high internal quality leads to lower maintenance cost, faster implementation of new features, less bugs and faster resolution of bugs. Thus, internal quality has a higher upfront cost but leads to lower total long term costs, whereas software with lower internal quality has a lower upfront cost, which means that the first release is after, but all subsequent releases take longer, and there’s much more bugs.
Software with high internal quality takes a bit more upfront time but adds to developer productivity in the long term. So overall, considering the total lifetime of software, internal quality is critical.
\