The only two levels of software quality

Our new video on the two perspectives on software quality

One thing that has always bothered me about fixed-price projects is that quality is usually the variable. Once the time frame, budget and feature set are agreed, all that's left is the quality, which has to be adjusted as the project progresses. This will always result in the same outcome for the client: poor quality.

In a fixed-price model, contractors are incentivised to save their own time and money by reducing quality to the lowest possible value for which they will continue to be paid and hired in the future. This is not a good incentive - and the reason why we don't do this kind of project at interfacewerk.

In any project that is to achieve a good end product, the variable should not be quality, but the number of features. If the stakeholders agree on a time frame and a budget, then the feature set must remain flexible - because quality is not negotiable. Why is the number of features so crucial for the quality of software? More features means higher complexity, higher complexity means a worse user experience, which in turn - you guessed it - degrades the quality of the product.

However, there is another intention where software quality plays a different role. What if the result does not have to become a lasting product? Sometimes, e.g. as a start-up, we don't want to build something sustainable right away, but want to learn quickly. To enable quick learning, quick prototypes are the best way. A quick prototype with a few core features cannot and should not have good quality - otherwise it would not be a prototype but a finished product.

So once again it comes down to intention. Do you intend to learn something and then throw it away? Then you can quickly achieve the goal of generating knowledge with a simple product. Do you intend to build something that will last? Then you need to build it in the best quality you can achieve.

Written by: