Good enough software: quality, risk, and diminishing returns

What level of quality do you need for your software system? As usual, it depends on the context. You will need different things in a startup where the product has not yet been proven to work and in product that is in active use by a large amount of users. Time is also a factor, what was good enough software 15 years ago is likely not good enough software anymore.

Bad quality is expensive, and risky

Bad quality can be many different things. The software might be hard change, resulting in increased development costs. These hard changes might introduce bugs that result in loss of revenue, decreased user satisfaction and so on. The normal practicalities to build, deploy and monitor your software might be inadequate or non-existing, causing repetitive actions that take time, and again cost more.

Bad quality is lacks in implementation, tooling, functionality or maintenance that make generating the desired business value more expensive than it should be.

Bad quality can be, but is not always, technical debt. Technical debt and bad quality on certain areas is also a risk. Maybe you are unable to fulfill a contract in time because the software was so hard to work with or maybe the instability of the software causes your customers to look for other solutions. A defect in the wrong place might end up costing you a great deal more than fixing it would have ever cost.

Too good quality is expensive

Too good quality, or overengineering, on the other hand is everything you have in place, but is not really needed to provide the desired business value. This can be an elegant implementation in the code that takes time build to solve an issue that could, for the purposes of generating the desired value, been implemented in a faster and a simpler way. Maybe you have developed capacity to serve a millions of users and it cost you significant amount of time and money, but you don't actually have that amount of users and could have gained the same level of service with a cheaper alternative.

Additional cost for something you do not need is too good quality. If something is expensive, but you need it to reach your target it is not 'too good'.

Context is key here. The same thing can be complete overengineering in one context and an absolute must-have in another context.

Too good: an asset or a risk?

There is a temptation to consider that having something you don't need is an opportunity to utilize in the future. This is only true in case you know for certain what happens in the future, and as you probably know, this is rarely possible. Admittedly sometimes we do get lucky, but that is a shallow strategy.

Demands for a software system are notoriously volatile and might change a lot over time. Your asset might turn into technical debt if the requirements change into an unexpected direction. There is not much to protect you from requirements that change in a way that you now have something that used to be necessary and turns out to be a burden in the current reality. But do not intentionally include capabilities you do not need as they might turn out to be a lot more expensive in the long run than you imagined.

You might get something for free as a side-effect of fulfilling some other requirement, which is a bit different situation as no specific effort was used to gain it.

Quality and diminishing returns

Let's consider this in the context of diminishing returns. Fitting the law of diminishing returns into software quality we would say that the output is business value, and the input is quality. Examining the graph above we could say that there exists a point where we have everything that we need (Point of Diminishing Returns). There also exists a point after which every improvement is unnecessary for our purposes (Point of Maximum Yield). In the area of diminishing returns, you have everything you need, but further effort will still provide net increases in value.

It is quite a stretch to put the entire quality of a software system into a single concept "quality", we instead could consider this per quality attribute.

Let's say the usability if our system is good to the point that there is little point in improving it to achieve our goals. At the same time our CD capabilities might be lacking, causing extra manual work, and we could improve our efficiency by improving the deployability of our system over the Point of Diminishing Returns.

The trick is knowing what matters. Not all quality attributes are equally important for the system you are developing, but some are very important. Several quality attributes are somewhat important.

When the relevant quality attributes for a given software system land in the area of diminishing returns you have good enough software. You are past the point where you could gain large benefits by improving quality and at a point where a cheaper solution would not result in any meaningful cost saving without sacrificing value. If you have quality attribute scenarios, this would be the situation described in them.

Good enough software might not be the shiniest cool technical innovation mankind has produced. It gets the job done and brings home the bacon.

(Though depending on your context, good enough just might be the shiniest cool technical innovation).

Bad quality then is being in the area of Increasing returns, because improvements in this quality attribute would result in significant increase of net business value.

Too good quality on the other hand is being in the area of Negative returns, since lesser effort would have produced you the same (or better) net business value.

With this we can define net business value as: Net business value = business value - total cost of ownership. It might be hard to accurately turn this into monetary terms, but it can still serve as a heuristic.

Quality is subjective

Quality is context dependent and subjective. For some purposes X is essential, for others it is waste. Quality is also often subjective. The task is to try and figure what matters to your stakeholders, target audience and your development team. Your own preferences will inevitably be included to some degree too.

Quality being a quite hard to define you will likely discover at some point that something that you thought is not so important might be quite important to reach the desired business value. The reverse also applies, something that you thought would be essential might not be in the end. These shifts in understanding are one part of the process that creates technical debt.

It is impossible to know for sure so try to investigate as well as you can before creating something new. After that keep following the feedback you receive, the technical performance of the software, the efficiency of the development team etc. When you make architectural decisions think how these will affect the software in the long run. What will get harder to do and will it enable something new.

Since quality is hard to quantify, our perception of our situation of the quality attributes' status in terms of diminishing returns will be largely subjective. For this we should make a best effort with the development team and stakeholders to see how we perceive the situation of the important quality attributes.

Managing quality in a messy world

In a perfect world we would know exactly what will be needed and have time & money to implement everything perfectly. Since this is rarely the case, focus on what is most important. Identify what quality attributes are most important for your software right now. For each of these quality attributes identify where you are at considering the Law of Diminishing Returns.

This is more or less a never ending process as the world around us changes and we usually do not have the capacity to make everything as good as it could be. Find out what effort has the highest return of investment and work from there. There is always something to improve and we want to improve what matters. You don't necessarily need to start creating graphs of your quality attributes on regards to diminishing returns, I consider it as a heuristic and attitude when considering what should we improve and how much.

Considering the diminishing returns is also a way to control perfectionism. Don't chase cool tech for the sake of the tech and as reversal don't unnecessarily create technical debt. Pragmatism is to fulfill the requirements as effectively as possible while keeping most options open for possible future needs. To be pragmatic is to create good enough software.