Menu
Most consulting engagements start with assessments of an organization’s current state. Very often, the interview’s that you conduct reveals a lot about the current state of the organization. Once in awhile you come across a statement that an interviewee makes during one of these interviews that make you think. During a company testing assessment, an interviewee said:
“Testing is something everyone wants, as long as it doesn’t cost anything.”
Isn’t that the truth! While it seems that everyone understands the need for quality, it is always the first thing that is sacrificed in some organizations.
Why is the discussion of software quality so divisive? For some the cost of bad software is obvious and yet for others, their focus is to deliver the software at all costs. Logic would dictate that delivering quality software would be an essential criteria for all organizations.
In some organizations that deliver life dependent software, there is no discussion on quality. Quality is top of mind for everyone on the team because everyone knows what is at stake. Once you move beyond these industries, the software landscape is littered with examples of failures due to software problems. Here are just a few examples:
NIKE Inc (2001) : Problems with supply-chain management system results in a $100 million loss.
Citigroup (2016): Software bug costs Citigroup $7million
Not to mention how many software projects just get cancelled and never go live despite hundreds of millions of dollars having been spent to try to deliver the software.
One of the common reasons that get cited on why software problems occur is the need to stay ahead of the competition. Software teams are being asked to deliver faster so that businesses can compete. Smartphones and the Internet of Things (IoT) have made that competition even more fierce as software is now in almost every corner of our lives.
The proliferation of smartphones has not only increased competition but also made software companies more adventurous when delivering software. The everyday use of smartphones by the general public has trained most people on the need to update their software. Even the most basic user of a smartphone knows about software updates. Software updates can be pushed to millions of users at the push of a button. This has lulled many software companies, regardless of the application, into a sense of comfort by thinking “we can just release a patch if we get it wrong”.
On the other hand, companies that develop software also know that whenever there is a problem in production, there are many indirect costs to that problem on top of the direct costs of productivity loss, and the re-work that has to be done to fix the problem. How many companies actually measure the indirect costs? In my experience, not many. Most companies just don’t worry about it because they want to fix it as quickly as possible so that they can work on delivering the next big feature.
Adding new features to software is usually a fun creative time for a software team. The team wants to develop the best quality software possible. However, the excitement of building new software quickly gets tempered by the reality of having to deliver by a given date.
The pressure of a date often leads to a discussion about quality. This conversation occurs daily in many organizations. It goes something like this:
Mr. Get it Out: We have to cut the quality on this project because we are running out of time.
Ms. Do it Right: Yes but if we cut the quality, then their are risks that it will blow up in production and we will have to fix it later.
Mr Get it Out: We just don’t have the time to do it right….
Ms. Do it Right: But we have the time to do it over and over again?
Inevitably the software gets pushed out at all costs and a problem happens in production which leads to budgets being wasted on re-work and the many indirect costs that are incurred by the company. Some organizations actually track re-work with a budget line called “Break and Fix”. However, the purpose is not to use it to analyze what went wrong and look for ways to improve, but purely as a CAPEX/OPEX budgetary exercise.
In many engagements I have advised organizations that “eventually bad software quality will catch up with you”. The costs may not be evident but everyone knows the costs are there. Therefore, rather than looking at software quality as an expense, look at it as an investment.
If software quality is done right by using techniques of building in quality rather than trying to test in quality, then the investment will more than pay for itself. You will be able to deliver more features because you will have more capacity from the reduction in re-work. More importantly the company’s reputation will be seen as one of quality and that has been shown to be a differentiator in many of the top software companies.
Build a culture of quality in your organization. Your customers, employees and your bottom line will thank you!
If you want to know more about how to build a culture of quality so that your engineering teams are building in quality rather than struggling to test in quality, please contact Avant for a consultation.