Do you have a quality strategy for your software?

“We want good quality software!” So says every client.

“We build good quality software!” – says every software developer.

Brilliant! But what does that mean in reality? I’m willing to bet that the definition of quality that your software development team uses isn’t the same as yours. I’d also be willing to bet that even within the software development team and the client team, each member defines it differently.

While writing this article, I got a very timely email from my Tech Leadership mentor, Marcus Blankenship, discussing this very thing. In it, he said that _ quality is always subjective, personal and political_.

He’s spot on. The differences between everyone’s unspoken definitions of quality are where most problems and mismatched expectations stem from on a development project.

In a previous article, we talked about who pays for fixing the bugs and ended with a seemingly unsatisfying conclusion if you’re the client. This outcome is what results from different (and unspoken) definitions of quality. The client expected good quality software. The developer likely implicitly promised that they would deliver good quality software, but no-one took the time to agree what it meant.

Driving out the risk

When you commission custom software, you must remember that you’re not buying a finished product like a kettle or a car. When you buy a finished product, it is reasonable to assume that it will work well, and the vendor will warrant its durability and quality for a suitable warranty period. That’s because they have driven the risk out of the product and spread the warranty cost amongst the many buyers. With bespoke software written especially for your business, there is a buyer of one—You. On top of this, you are also creating the first instance of the product. There is a significant amount of risk that you have to shoulder. That’s why there has to be a clear-cut financial upside to proceed. You, as the client, take the risk and also receive all the rewards.

When it comes to software, we’ve already established that bug-free code is something to strive for, but rarely achieved. Examples of similar problems abound from organisations in every industry. Cars get recalled with safety problems, NASA has lost multi-billion dollar rockets, and software from vendors as large as Microsoft and Apple all contain bugs. There are diminishing returns to driving every bug out of a system. The key is to mitigate the most significant risks and apply available resources and budget most efficiently to minimise faults.

Define your definition of quality

Here, at Foxsoft, one of the best ways we have found to get client and developer on the same page is to jointly agree on a Definition of Quality at the outset of our working together.

We find out what quality means to the client. Then we can have a frank discussion with them about how we should measure and meet this definition. We’ll agree on how we will strike a balance between adequate testing and the cost of development.

By ensuring that we start out with a clear definition then every member of the team has a clear idea of the quality level we’re working toward and how it impacts the project in both time and cost.

There is no one-size-fits-all. It naturally will be different for each client, and each project. For example, a short-term prototype doesn’t need lots of testing, nor does simple functionality which is used rarely. Contrast that to crucial financial calculations that have a direct and material effect upon the business if they are incorrect. There is a lot more value in spending extra effort at the outset to ensure that the correct results are produced.

It’s not merely about testing; there is a multitude of other factors to consider, some quantitive, others more qualitative. For example, brand perception and reputation might dictate a specific strategy. If the website is public or client-facing, then you might want extra assurances that even trivial things aren’t broken which would result in the impression that the company doesn’t care. I’ll dig into more of these in future articles.

The important thing is that the client articulates the quality level needed for each aspect of their system. Of course, none of this means that the development team gets to abdicate responsibility. The team should still be employing appropriate quality practices and always looking to learn and integrate new, better approaches. If not, maybe you should fire them.

Are you looking to improve the quality and reliability of your web-based application? Talk to us for a confidential, impartial and no-obligation discussion about the issues you’re facing.