Software Quality as Perceived Risk Part II
After the 1st article I got a very interesting question: Now that we know the problem, how to fix it so we can finally quantify quality on a software application.
To first quantify quality, we need to define what is quality and there is a whole bunch of perception that comes into play in this. For example, the Toyota Corolla and the Kia Optima are equivalent cars therefore they have similar quality but Toyota is always perceived as having a superior quality for reasons which are usually hard to understand when explained by customer versus the manufacturer.
As a driver I love my Kia Optima and I know that I would have a hard time in selling the Optima as a better car to a current or former Toyota owner. If both cars have similar quality why is one perceived as a better car than the other? The answer for this is quite simple: humans aren’t machines that process binary logic, a lot of emotion is placed into our decision taking.
Quality is a matter of perception and it will be different for each of audiences Product Owner, Clients and Investors and, although there are different messages to be given, they must in the end confirm that your software application has quality.
The perception of quality for a product owner is in regards of risk. If the application has lower risk to be in production this means that it will have a lower cost of technical debt giving more time on development of new features. Although I made the association of risk and technical debt, truth is that risk management has a lot of other facts into it to be accounted. Unit tests, technical debt, complexity, likelihood of generating a bug, etc.
What is really important is the mathematical association of the higher the risk the higher the odds of technical debt and therefore the higher will be the cost.
Measuring quality from a client perspective has to be done in a daily basis. That is done by count of tech support calls it generates and by the churn rate (the rate which customers stop subscribing to your application).
An application that has a low churn rate and a low number of tech support calls means that it has a high success rate, therefore, high quality. Tech support calls consumes time and a large amount will consume more personal which means that costs that could been used for a given improvement is now being directed to the support of production issues (technical debt). A high churn rate means that the application has something that is generating a high drop in the average daily subscriptions for the application, which has a direct effect on the revenue that the application produces.
The fun part is measuring quality for an investor. If you are familiar with TV shows such as Shark Tank you will know that all of the investors are asking is the same thing: what is the risk and what are the current growth. That is asked so they can successfully measure the ROI (return over the investment).
When you are pitching your application to an investor so you can successfully grow it, you will be providing to him mainly the churn rate and the current profit and this is where it becomes hard.
When the application is starting is very hard to get a large investment or a investor to join (not saying that it is impossible), which makes the team responsible for it the 1st investors, but when attempting a secondary investment for growth, then you must present data and that means:
- How much gross revenue the application has done so far
- What is the overall client acquisition (subscriptions)
- What is the predicted client acquisition for the next 5 years
- What is the current churn rate (same churn rate that we measured with clients)
With all of this one can use the following as a way to quantify quality from the perspective outside of the engineering team:
Average Net profit vs Churn rate
Where the average net profit is the amount of average of gains already discounted from the losses and the churn rate is the percentage of losses that you have on subscriptions.
A high average net profit with a low churn rate is the equivalent of a successful software application and that is the equivalent of a quality product.
When it comes to the Engineering Team, all the points mentioned on the 1st article are the least necessary to ensure a sound quality product.
