Internal quality (aka structural quality or architectural quality) is an assessment on the quality of the code and its underlying architecture. It differs from external quality which assesses how good the software is in relation to the requirements. Nowadays, as building large scale applications is becoming increasingly common, assessing it, is becoming increasingly important.
The time when one person was writing and maintaining software has long since passed. Nowadays, software is usually developed by hundreds of people. For example, Windows NT 1.0 (1993) was developed by 200 developers and 140 testers and it had about 4-5 millions of code. In comparison, Windows XP (2001) was developed by 1,800 developers and 2,200 testers and had over 40 million lines of code. In fact, nowadays the number of people involved in software development process is so large that lines of codes give the only small indication of what the process was really like.
Bad internal quality is not necessarily a consequence of bad design, but more of the constantly changing user requirements and the design not being adjusted accordingly. This is when we step away from the perfect world and take the journey to the realms of software engineering. In order to maintain a high internal quality, the code should be 'clean' to begin with and then adjusted accordingly with the changing requirements. Clean means: maintainable, flexible, portable, reusable, readable, testable and understandable. These characteristics are difficult to measure objectively. However unless met, introducing new features or fixing bugs becomes increasingly complex, time-consuming and consequently more expensive. However, investing in internal quality has medium to long-term benefits. Although the internal quality should be virtually imperceptible to end users, this is not always the case, because “difference between internal and external characteristics isn’t completely clear-cut because at some level internal characteristics affect external ones”.
One way to write high internal quality software is to use test-first programming i.e. writing the test code before writing the production one. This is the main principle in test-driven development. It turns out, that test-driven development is very effective as shown in the study by David Janzen. Unit tests give a good feedback about the architecture of the software. The definition of a good unit test:
- Automated and repeatable
- Easy to implement
- Can be used in the future
“Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with and as a result, the programming process will become cheaper. If you want more effective programmers, you will start to discover that they should not waste their time debugging – they should not introduce bugs to start with.”
However, the code will require refactoring, this is almost unavoidable in a large project, but thinking about the architecture of the software is very important, to begin with. Even if new bugs are introduced, good coverage of unit tests should allow intermediate feedback.