paint-brush
Financial Damage Caused by Software Bugsby@spekulatius
591 reads
591 reads

Financial Damage Caused by Software Bugs

by PeterMay 2nd, 2021
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Tricentis had issued a report on software failures in 2017. It was concluded that companies faced almost 1.7 trillion US dollars worth of software failures. This affected 3.6 billion of the population. In 2012 a server of Knight Capital Group was forgotten during a software update that created millions of stock orders. As a result, trades exceeded half a billion dollars within a short time. In the case of a recent tragic Tesla crash, which is suspected to be linked to the autopilot software, 3% Tesla stock decline amounted to around 20 billion dollars.

Company Mentioned

Mention Thumbnail
featured image - Financial Damage Caused by Software Bugs
Peter HackerNoon profile picture

As a software engineer, bugs are part of my daily life. I’ve developed a trained eye for bugs. Thanks to software errors, delayed projects are more the norm than the exception. Consequently, delayed projects cause high technical debt.

However, a better testing strategy can address the issue. I look at you puppeteer. But in software development, the budget for testing is often the first one to get reduced in favor of more features.

Economic Damage from Software Bugs

What's the financial damage caused by software bugs? Tricentis had issued a report on software failures in 2017. It was concluded that companies faced almost 1.7 trillion US dollars worth of software failures. This affected 3.6 billion of the population.

Let's have a look at a case study. In 2012 a server of Knight Capital Group was forgotten during a software update that created millions of stock orders. As a result, trades exceeded half a billion dollars within a short time. The owners bailed the company out with 400 million and the stock price fell by 75% within two days. This is an extreme example, but not a single case.

It doesn’t even need to be 75%. Even just 3% can amount to a large sum, given the company is considered the most valuable worldwide. In the case of a recent tragic Tesla crash, which is suspected to be linked to the autopilot software, 3% Tesla stock decline amounted to around 20 billion dollars. This exceeds the GDP of a small nation.

‘But We Can Just Fix It Later’

Yeah, sure. But the costs of fixing it later are much higher. A bug discovered in various phases leads to more work:

  1. Requirements phase: The requirements need to be changed. The costs are minimal.
  2. Development phase: Development time isn’t cheap. Costs vary on the type of bug and the way it’s been discovered.
  3. Testing phase: If a tester identifies the issue, the costs are coming from the tester’s time to test, document, and communicate the issue. On top of that, the engineer’s time to reproduce the issue and fix it, are also added with the costs
  4. Client Testing / UAT: The costs increase by the client’s time needed to test and communicate the issues. Usually, the issue goes back to testing to verify the issue and ensuring it’s an actual bug. Afterward, the developer again needs to reproduce and fix the issue.
  5. Production: If a bug is noticed and reported by an end-user or as part of logged issues, the costs are again higher. This is due to the need to backtrack and review the issue. In addition, a production deployment is required to fix the issue. Solving the issue depends on the operational setup; between minutes or days.

As you can see, bug-related costs are increasing with each step. With IT services generally on the upper end of the price scale, this is a lot of wasted effort.

A Solution to Avoid Technical Debt 

Testing shouldn’t be a secondary priority. It’s nothing you should “add on later” or “when we have more time”. Testing needs to start at an early stage of the project.

The development of best practices plays a big role here. Ensure to have enough time for test-driven development. Make sure to cover end-to-end testing as well.

Towards the end of testing, there are a few questions that need to be addressed to ensure future problems won’t arise:

  • Does the application work? If parts aren't working as expected, what is planned to do about this?
  • Are all features operating as they should?
  • Can the application manage high traffic?
  • Are there any risks that would put the users in danger?
  • Can the application be used with ease? 

Also developing a software testing philosophy is imperative. This would include developing a testing culture, building a group of standard testing preparation tasks, implementing test methodologies, improving the effectiveness of the test process, and the appropriate way to use the final outcomes.

I like to write, do you like to read?

If you liked my article, you might want to check out my dev blog or business blog. I occasionally send out an email for those who are interested.