5 Ways to Improve Software Quality
Viktor Clerc
on 29 November 2021
Many opinions exist on what software quality exactly is. Clearly defining the quality characteristics of software proves quite difficult. This holds from a functional perspective (‘it should just work!’), as well as from a non-functional perspective (‘the solution is slow…’). In this blog post, we will sketch the arena and provide five useful tips to define and improve software quality.
The thing about software quality is that it is more difficult to verify its presence than it is to verify its absence.
For example, systems of poor modifiability cannot keep up with changing business requirements – these systems are often perceived as having insufficient quality. At the same time, we often tend to recognize the elegance of using appropriate architectural patterns or design patterns to solve a problem – unfortunately, software architects or engineers can get carried away and over-apply these.
At Qxperts, we build on a series of business indicators that allow you to make software quality tangible. We highlight two of them:
These indicators are about speed and value. This requires a balancing act. Does your business prefer the right software now as opposed to better software tomorrow? When is good actually good enough? Nobody wants to end up with poor quality software that breaks all the time, nor does anyone want to gold-plate their solution before putting it to the test in production.
Five key elements contribute significantly to improving software quality. These elements cover a process, people, and a technical perspective. In our experience, the combination of these perspectives yields the best results. The five topics are listed below and discussed in turn.
There is a lot to say about each of these five topics. We will provide follow-up reads for some topics, and continue to add more follow-up reads as they become available.
Too often we observe misalignment between business and IT. Since ‘communication’ is often defined as ‘the subtle misinterpretation of one another’, it is important to double-check the use of terminology and spot and resolve any differences in interpretation.
Misinterpretations are easily made, even without noticing them. That is why it is important to allow misinterpretations to surface as early as possible. A great way of achieving this is by creating a shared sense of reality on the problem domain. Techniques such as EventStorming and other means of visual collaboration can help. Similarly, it is also important to uncover each stakeholder’s perspective on software quality. Only by making these potentially different perspectives explicit, can one derive the proper indicators for what it means to have a “good product”.
A few useful questions you can ask to navigate such a session would be:
One of the elements that is (still) often overlooked, is to specify quality in terms of non-functional requirements. Think about the maintainability or changeability of the solution. Software engineers and architects may take different technical decisions when designing a system that is expected to change often. What about the performance of the system, the number of intended users that simultaneously use the system, or the number of messages that are processed in a given time frame?
A multitude of standards and mechanisms exist to specify non-functional requirements. Have you taken a look at the (somewhat overwhelming) ISO/IEC 25010:2011? This standard contains a quality model that can help you facilitate the discussion regarding maintainability, time behaviour (e.g., performance) or interoperability. By further translating these into requirements using the S.M.A.R.T. format, you enable these characteristics to be testable and verifiable when they are developed and delivered.
A development process should offer flow and transparency, so that the predictability of the process is adequate. In this way, high-quality input can be translated into high-quality output. Think of it as the equivalent of a Michelin-star kitchen staff, where everyone is aware of what they need to do at any given time to achieve predictable results. A development process with flow and process transparency (in terms of tools but also communication) offers room for experimentation and space to pro-actively spot potential issues and quickly implement improvements. A good way to see how flow and process transparency may be improved is by utilizing techniques such as value stream mapping.
Furthermore, it helps to instill a whole-team quality mindset where the responsibility for the quality of the product lies on the shoulders of the team (supported by proper processes and tools).
The principles of continuous delivery are key in achieving fast feedback to the development team. Frequent deployments in small increments enables organizations to verify the effects of those increments rather than waiting for the one and only release. The necessary infrastructure that supports continuous delivery (automated builds, automated testing, automated provisioning, and automated deployments) should be implemented and be meticulously embedded in the complete delivery process. As a result, the technical setups are equal since environments are described in code. This significantly improves the repeatability across various team members and prevents ‘quirky situations’ such as repeating certain tests until they are ‘green’, a.k.a. “it must have been the environment”.
Furthermore, modern CI / CD pipelines allow for the integration of automated quality assurance tools, such as code quality scans, language linters, and dependency and security checkers. A possible way of providing these technical setup to a large number of development teams is to introduce the concept of a Paved Road. As a result of using a Paved Road, developers spend less time on going line through line during peer reviews and hand the routine work over to tools. In other words, software craftsmanship can flourish and act upon fast feedback once the infrastructure is in place. That said, tools alone will not ensure high-quality software if development teams are not aware of bottlenecks or are lost within their own codebase.
Traditionally, a lot of emphasis is placed on the software delivery process and measurements that help while developing software. It is equally important to implement functional monitoring – is the product indeed resulting in the predicted benefits?
Use the different perspectives of ‘good quality’ identified in the interactions with the business and translate these into the quality indicators that can be measured in production. E.g. most often used functionality, most revenue-generating use cases, behaviour of the system related to the user base, just to name a few. So, put some TVs in the office rooms and have them show dashboards and other important metrics. Let development teams see the value they deliver for themselves. Refer to the blog post of my colleague Bert Rijsdijk on Improving Functional Monitoring for more information.
Typically, a thorough and holistic overview of the existing situation proves to be a good starting point for setting clear improvement goals. An approach that focuses on team organization and interaction, the software delivery process, and the technologies used for both software delivery as well as the actual product being developed. The assessment results in the identification of key improvement points along the axes described above and the roadmap on how to implement them.
Addressing these improvement points will help set organizations up for success. Interested in taking the first steps or finetuning your journey? Let us know!