Imagine a stunning mansion with a grand facade that appears like a dream come true. Upon closer inspection, however, its foundations are crumbling and it is almost falling apart. You can say that it has a high-quality exterior but a low-quality internal structure.

In a similar fashion, there are two types of software quality: external and internal.

The software can be very easy to use, and it might work fast (external quality) but it might be difficult to add new features to it because of the messy spaghetti code (internal quality).

It can also be the other way around: the software’s functionality can be easily changed (internal quality), but its performance can be terrible and it might crash frequently (external quality).

The following diagram visualizes internal and external quality, including examples of both:

External quality is how users perceive the software or the product. For example, they might want it to be easy to use, work as intended, and do things quickly. Usually, when you hear people talking about the quality of an application, they are referring to external quality.

Internal quality is what developers are aware of and care about. It is things that you cannot directly see or experience when using the software, but that have an effect on the development and costs of the software. For example, maintainability and readability of the code are aspects of internal quality.

External Software Quality

The external quality is the perceived quality of the system that users experience when using the software. It is something that users pay attention to and are interested in.

Usually when users discuss the quality of software, they are referring to the external quality. For example, they can say things like:

• “I love how easy it is to use this website!”
• “This app crashes all the time!”
• “It takes forever for this page to load…”

These are all aspects of external quality, and many other factors can also affect the perceived quality. I have listed the most important ones in the table below:

How to improve external software quality?

Measure it

To improve external quality, it is essential to measure it. Without measurement, how can you be sure that your quality is improving?

The customer satisfaction is your single most important indicator, as it encompasses a wide range of factors. And customer feedback is the best way to identify what you need to do to improve the quality.

Some other metrics to measure external quality:

• Page load time
• Uptime
• Change failure rate
• Number of open bugs (bug depth)
• Number of customer reported bugs per sprint

You need to consider which metrics apply to your software/business and put most effort into those.

There are tools available that you can use to automate measuring some of the metrics. One example is an open source tool called sitespeed.io that you can use for performance testing of your website.

Once you have established measurements and metrics, you can find the bottlenecks. Decide which ones you want to tackle first, and create actionable tasks on how to remove the bottlenecks.

Additional tips and techniques for improving perceived software quality

• Automated testing tools: Use automated testing tools to enhance testing efficiency. This not only reduces the manual effort required for testing, but also ensures a shorter feedback loop and faster identification of potential problems. These tools can perform a variety of tests, such as unit tests, integration tests, acceptance tests, security tests, or performance tests. Focus on automating the most important tests first.
• Manual testing: Automated tools are useful, but they cannot completely replace manual testing. In addition to testing functionality, manual testing can be used for tasks such as usability testing or penetration testing. Usually, including some amount of manual testing in your development process is good for improving quality.
• Define acceptance criteria for the backlog items: Clearly defining acceptance criteria for each backlog item ensures that the development team understands what is expected of them and can work towards meeting those expectations. This can help improve the quality of the software by ensuring that each feature meets stakeholders’ expectations.
• Define the definition of done: The definition of done is a simple checklist of activities that needs to be completed for every backlog item to be considered done. For example: code, unit test, code review, add logging, design documents, release notes, meet acceptance criteria etc. Establishing a clear and concise “definition of done” can help to ensure that all team members and product owner have the same understanding of when a backlog item is complete.
• Use Continuous integration and delivery (CI/CD): CI/CD is a development practice that involves frequently integrating code changes into a shared repository and automatically building, testing, and even deploying the software. This allows faster feedback and reduces the risks for example by avoiding the last-minute chaos at release dates.
• Work in small batches: Working in small batches is a lean practice often used in DevOps processes and closely related to CI/CD. This involves breaking down large tasks into smaller, more manageable pieces. In practice, “small” means something that can be complete within a few hours. If it takes a day to complete, it’s considered large. Ideally, you would commit multiple times a day, with each batch being reviewed and tested on its own. Smaller changes are easier to test and validate, which shortens the feedback loop and allows you to get feedback multiple times in a day.
• Have testers and developers in the same team: Having test engineers and developers on the same team can improve communication, understanding, and cooperation. This can help to improve the quality of the software, as issues are identified and addressed more quickly, and testing is more tightly integrated into the development process.
• Root cause analysis / post mortem: Performing a root cause analysis or post mortem after each major production issue has been resolved can help to prevent similar issues from occurring in the future. This kind of continuous learning and improvement can significantly enhance the quality of the software in the long run.

Internal Software Quality

Internal quality of software is something that your users cannot directly experience or see, but it is something that you should be interested in. It refers to the quality of the code base, design, and architecture of the software, and thus it can affect directly to the efficiency of software development.

For example, “spaghetti code” that is hard to read is a sign of poor internal quality. Code should be clean, self-descriptive and written primarily for humans.

In the following table, you can see some of the most important attributes of internal quality:

If the users are not interested in the internal quality, why does it matter at all?

Poor internal quality leads to poor maintainability. Over time, it would be very difficult and time consuming to add new features or change existing functionality to the software, if its code is a mess. You will also introduce new bugs more easily, which will lower the external quality and customer satisfaction.

“It is obvious that components with low score in the internal metrics will also have low score in external measurements.” -Dimitris Stavrinoudis, Michalis Xenos

In the short term, you may get away with poor internal quality, but soon it will come back to haunt you. You have heard the term “technical debt”, haven’t you? It is called debt because you have to pay it back.

Good internal quality, in turn, helps to improve the external quality. And higher external quality means higher customer satisfaction. Higher internal quality also reduces long-term software development costs, as it is easier to modify the code or add new features.

How to improve internal software quality

1. Measure it: You can measure the internal quality by using quality metrics, which are implemented in static software analysis tools. There is no scientific agreement which metrics are best suited for this, but there is an agreement that the metrics provide information about the internal quality. Some of the most common metrics are:

   • Cyclomatic complexity (McCabe)
   • Halstead metrics
   • Maintainability Index (Microsoft Visual Studio)
   • Lack of Cohesion in Methods (LCOM)
   • Depth of Inheritance

   For example, Radon is an open-source tool for Python to calculate McCabe’s complexity and Halstead metrics. Radon can also calculate the maintainability index, which is a hybrid metric combining some traditional metrics, and thus it might provide more reliable results than any single metric.

   To improve internal quality, set up a tool in your CI pipeline to measure the metrics on each commit or merge. With measurements, you can see if you are heading in the right direction.

2. Create boy scout culture: Improving the quality of your code is a bit like keeping a campsite clean. You know the boy scout rule: “Always leave the campground cleaner than you found it”? Well, it’s the same with code. Always aim to leave the code in a better state than when you started. Become familiar with clean code and encourage its use.

3. Review all the code: Establish a common practice with your team to go through each other’s pull requests to check it’s all okay. Create a checklist of what to check during the reviews. Take into account different internal quality attributes.

4. Make refactoring part of your development process. Refactoring means changing the structure of the code without changing what it does. It helps keep the code clean and manageable. Refactoring should not be a separate task that is added to the backlog, but you do it in your normal daily development process.

5. Follow design principles: Use proven software design principles like DRY (Don’t Repeat Yourself), YAGNI, KISS (Keep It Simple, Stupid) and SOLID.

6. Prefer composition over inheritance. Using composition instead of inheritance generally improves the internal quality by giving the design higher flexibility.

7. Use loose coupled architecture: Loosely coupled systems are easier to maintain because modifications in one part of the system do not have a domino effect on the rest.

External quality vs. Internal quality

You might have a question about which one is more important in software product: external or internal quality? My answer is that focus on both:

• With good internal quality, it is easier to change your product to keep up with changing user needs.
• With good external quality, it is more likely that people will use your product and pay for it.

Therefore, you shouldn’t try to put them in order, but pay attention to both to have long-term success with your product.

The essential thing is to recognize that you can divide the quality into two categories, each with its own purpose and ways to measure and improve. This distinction helps you understand why certain tasks are important, what benefits they bring. This makes you easier to prioritize the tasks or backlog items to maximize the results you want to get.

Conclusion

We can divide software quality into two categories: external and internal.

• External quality is what users care about, such as ease of use and bug-free operation.
• Internal quality refers to aspects that are not visible to users, such as maintainability. To ensure long-term success, you must take both into account.

Improve the both equally to have long-term success with a software product.

Explore more

• Internal And External Quality (C2 Wiki)
• Is High Quality Software Worth the Cost? - Martin Fowler (Book)
• Comparing internal and external software quality measurements - Dimitris Stavrinoudis, Michalis Xenos (School of Sciences and Technology, Hellenic Open University, Patras, Greece, 2008)
• Design Patterns: Elements of Reusable Object-Oriented Software - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Book)
• Continuous Integration (Wikipedia)
• Cyclomatic complexity (Wikipedia)
• Halstead complexity measures (Wikipedia)
• DevOps process: Working in small batches (Google Cloud Architecture Center)

• Maintainability
• Quality