It was reported in 2015, that in the US alone that more than 15 bugs per 1000 lines of code was introduced to customers. And if that number doesn’t scare you consider that more than $113B was spent annually on identifying and fixing these software defects and that on average 50-75% of a developer’s time was spent on debugging code. Those are massive numbers that shows software testing and quality is not an unnecessary expense, but rather an important aspect of maintaining any company’s bottom-line. Yes, it was several years ago and only the US, but based on the evidence I am seeing in the software development world, I don’t think the numbers are too different today, regardless of the country. In fact, one 2016 article report suggested things were getting a lot worse.
Even if you think your code is of a good quality because your customers aren’t complaining much, there is a good chance that your developers are still spending far too effort in the development cycle fixing things that shouldn’t have been there in the first place. Considering that on average I takes around 30 times longer to fix a bug in a line of code than it does to write the code and you can further see that software defects are incredibly expensive on any company. If you want your development teams to operate optimally, you need to ensure that you have your testing and quality in order.
So, why is it that quality is still considerably poor or, put in other ways, our appetite for poor quality software remains? Well, the problem is not necessarily present in each company nor does it manifest itself in any one way, but I believe the following are key reasons why companies can become complacent in their attitude towards software quality.
Industry Tolerance
I think much of this has to do with the fact that software can be easily patched or the excuse that there are just too many variables to make quality sufficient. However, I would argue that those are simply excuses fostered within a culture we have allowed to create and society is simply just accepting of the fact that sometimes software just won’t work as expected and minor bugs are okay. We wouldn’t behave this way when we spot cracks in our house or find faults like this when we buy a car, but yet somehow, we accept it with the software we use.
It’s also a tolerance level that I believe is changing in the world and people are increasingly expecting software to work quickly and accurately or they simply just won’t use it. Which means that it is tolerance that few companies can rely on and need to address.
Many software teams can be very loose on their governance in the hope of “boosting” efficiency, but it also means that at times the number of issues introduced in the development cycle or the amount of time lost to those issues has been lost and companies are not aware of the problem,. While you don’t solve this problem with excessive time logging and controls, some sort of governance process and estimation effort should go into tracking issues and the time spent on them so that they can be remedied in the future.
Unwillingness to think long term
The added effort that goes into planning, design and building a decent testing framework on any project is a lot of extra time, not just from the amount of hours spent, but just from a dollar perspective. This added effort includes the likes of more detailed requirements and technical design that helps verify you are building the right thing. Writing your code in a more modular fashion that is often longer to write but importantly, a lot easier to test. And then also developing a complex and intricate automation framework that is definitely a lot lower than several rounds of manual regression. And often a lot more than that too – not even speaking of the people and process issues along the way.
This is something which big companies don’t mind as they might have the necessary capital, but something which start-ups generally can’t afford and so they move past it and take the risks in producing software that might not be fit for purpose long-term. However thinking long term, if you spend effort on doing this right up front, you avoid a lot of potential future issues.
Lack of Trust in testing
Perhaps the biggest reason why companies aren’t focusing more on the quality of their software is because they feel they’re tried it all before, with minimal success and so have lost the confidence that anything is going to be able to change this in their company. And there is some truth to that as there is no one silver bullet to fixing quality issues and the bigger the company, the harder it is to address. However, I do believe that companies should never stop looking to improve in this regard and rather embrace a move to more technical testing and afford themselves the time to rewrite their software where necessary to fix the big quality issues. It sound like a lot of work and it is, but if you want your company to still produce software that is relevant in the next twenty/thirty years, its lessons you need to learn and an adaptation that you can ill ignore.
Now I will say that even if you make massive inroads in addressing your testing and quality issues, you will still have them anyway. It’s unlikely you will ever be able to write perfect code that makes every customer happy, is secure, always performs quickly and never breaks regardless of the device and interface its working on. Those mentioned permutations alone highlight the difficult challenge that befits software quality and why production bugs will always be a part of development lives However, the numbers can be greatly reduced and you can develop an organization that is efficient and wasting less time on fixing defects as a result.