Bas Hamer, a full-cycle software engineer with 15 years of experience, talked about when a product can be considered “good enough” and in what way to talk about quality when it’s no longer about its improvement.
Quality horizon: why pay for something that is already “good enough”?
Why does business care so much about quality? Because defects are expensive. The amount you have to pay for them depends on the frequency of occurrence of defects, their duration and the transaction cost. But sooner or later, the moment will come when all 3 indicators will drop so much that people stop paying attention to them — this is the quality horizon.
Compared to the early 2000s, developers today prevent bugs much more effectively; they recover faster, can minimize the impact of errors depending on how many people they affect, and calculate the actual cost of a defect.
And this is kind of a horizon point: the cost of errors has dropped so much that some companies no longer need to work on improving quality. So why spend money on improving something already good enough?
What happens next?
- There is no point in wasting money on quality anymore.
- Further improvements may entail too much spending on software development.
To determine if this applies to your company, it is worth analyzing a few points. What is the maximum value of a defect? What is the culture of your company? Who are your customers, how demanding are they? Perhaps you have already come to the point where it is not advisable to invest in quality improvement?
And what is beyond the horizon?
Once the quality horizon is reached, we begin to talk about the defects that enter production as something normal. Because if we can fix it and its impact is small, the value of finding it is reduced.
All those tools, tests, reports that we have today in our arsenal suggest the desire for a complete absence of defects. But now we are talking about something else. With the “good enough” quality horizon reached, we are no longer interested in getting rid of defects completely. After all, we often use expensive integration testing, although recovery after a failure and fixing a bug could be much cheaper.
Be patient
Beware of the side effects of such an approach. Because if for some reason there is a problem in your DevOps team or the people responsible for site reliability, you will again return to the point where fast recovery is not possible, and you have to invest more in testing.
So be patient! You can refuse to conduct tests only if you are 100% sure that the quality of your product is “good enough”. After all, restoring full-fledged testing is not so simple. Another reason why you can’t completely eliminate expensive integration tests is because you can always find new, demanding customers who can bring in far more profits for the company than you can save by refusing tests.
