Agree on your Definition of Quality – or everyone will fight for himself

by | Oct 30, 2024

B O N C O D E   B L O G

Ask someone to define quality – whether in terms of software or any other product – and you’ll probably hear words like ‘good’, ‘high’, and ‘expensive’. These are the expected answers, but they evade the question. What does the word “quality” actually mean? And why is that important? 

One of the most popular and useful definitions of quality is: the extent to which something complies with the criteria set. And the keyword here is ‘criteria’, or ‘requirements’. Following this line of thinking: how can you achieve ‘quality’, if the criteria are not explicitly stated?. 

Meeting (or exceeding) predefined requirements for a software product is often forgotten in discussions about quality. And yet, without clear requirements, how can you meaningfully measure the performance and quality of a software system? Here’s why defining quality is so valuable.

Agree a definition of quality 

Unless you define ‘quality’ up front, every stakeholder in your software project is likely to impose their own definition, because they have their own implicit set of requirements. This can lead to inconsistency: particularly in large organizations where every stakeholder has an implicit set of criteria and therefore a personal view on quality. If these criteria are not aligned, then everyone might be doing the best from their own perspective – but not holistically as a team.

For example, software engineers might define ‘quality’ in terms of the codebase; a CFO could relate ‘quality’ to the cost of development; a database admin might view ‘quality’ in terms of their technical needs being met; a business owner might value ‘quality’ as the adaptability and future-readiness of the system; and users will probably judge a system on its features and looks. Not all criteria can always be met, especially when resources are limited. So how can we set priorities? What defines quality?  

Set a quality standard

As said already: every stakeholder has an implicit view of quality. Particularly in larger organizations, if there’s a lack of alignment on the definition of quality or, more precisely, the software requirements, then problems can start to arise. Although the criteria of one stakeholder is fully met (“we were on time with all the features!”) another stakeholder might be very disappointed (“yes… but technical debt has risen through the roof!”).

In order to satisfy all stakeholders in the short and long term, what’s needed is an agreed set of holistic requirements, which starts with a clear definition of quality. ISO 25010 can help with two key features of this: defining different aspects of product quality and providing a terminology to talk about quality. But it’s a starting point, not a complete solution.

Without clearly defined software requirements, it’s almost impossible to manage quality across an organization. Ultimately, consistency and improvement come from having a centrally agreed list of requirements. But there’s still a huge barrier to overcome. 

To non-specialists – such as nontechnical board members – software quality is still an abstract concept. It’s hard to relate software quality to tangible business objectives. Business leaders may not be interested in the technical details, but they are interested in the effects that high-quality (and conversely low-quality) software can have on business operations.

The key question is this: how do you turn technical metrics into meaningful data that can enhance decision-making? 

An important part of the answer is: introduce software metrics that indicate code- and architectural quality (aka technical debt) and agree on a threshold of what is acceptable. 

Share a language for ‘quality’

BonCode’s platform for monitoring and assessing the quality of custom-coded software systems helps technical teams visualize software quality so that everyone in the organization can understand it. That universal language gives stakeholders ways to discuss ‘quality’ so that it’s relevant to their own requirements. 

Software architects and engineers get the technical insights they need, while business leaders get just enough information to gain clear oversight and have meaningful conversations about quality in a broader business context. Measuring different aspects of software brings consistency to conversations about performance. It brings about better communication. 

Need to improve communication around the quality of your custom-coded software systems? See how BonCode’s tool-based consultancy can help. Book a free demo

You may be interested in this:

Why Software Architects Are Important People

Why Software Architects Are Important People

When you’re a software architect, you have an important role in planning design, systems, and delivering custom-coded systems. You’re a key decision-maker when it comes to functional design, technologies, and code structure. Such a role comes with responsibilities....

5 Ways To Increase Velocity In Custom-Coded Software Projects

5 Ways To Increase Velocity In Custom-Coded Software Projects

Velocity – the measurement of work done within a given time period –  is a valuable metric for software development planning. What makes it so useful? Not only does measuring velocity give your development team greater adaptability to changing requirements –...