It is always cheaper to get software right the first time rather than fix it later. To achieve higher quality levels for our software we need to rethink how it is produced. Software today must be innovative, and it must be developed with agility. But often, when software is handed over to the end consumer, or just before that, testers or end users find malfunctions, or that the code does not serve the purpose. This is true for both business and consumer applications. Making the resulting fixes is time consuming, as well as costly, and frustrating. That’s just the opposite of what we want. Improving software quality is thus one of the biggest and best ways companies can save money, improve their brand and generate more business.
Quality is a strange animal–nobody really cares about it until it is missing. But like property and casualty insurance, as soon as there is an incident, software quality (or the lack thereof) becomes everyone’s focus.
At Cognizant we have worked with clients for more than two decades to build in quality to their software from the start, using a lifecycle approach. Like in manufacturing, quality needs to be built in and monitored at every stage. From the first idea through development and into production support, the appropriate quality assurance activities need to be planned and executed to ensure a market-ready, industrial-strength solution emerges at the end of the software development lifecycle.
As digital technology and connectedness accelerate in the pandemic age, the challenge of inferior software affects an increasing number of industries and end users. Increasingly, the mechanics of software development are merging with the extended business value of what software enables. That creates a big challenge for industrial manufacturers of physical products that include software, because the quality of most software is not close to the maturity and quality of most hardware.
Hardware product quality has made huge strides in recent decades. When we went on a car trip back in the 1980s, we accepted that on a long distance journey something would go wrong and we would need to call AAA to help us get moving again. Today, cars require almost nothing but routine maintenance. They rarely break down, because their mechanical engineering is top quality. When Henry Ford built his Model T, quality was not much of a consideration. But as the auto industry matured, a major opportunity to differentiate with quality emerged. And then a small player, Toyota, shifted the paradigm of mass production to “stop building if the quality is not right,” rather than fixing problems at the end. The result was a dramatic reduction in costs on a cost-per-unit basis, improved brand recognition, and a complete rethinking of quality in a mass production context. Toyota eventually grew to become the world’s largest car maker. “The Toyota Way” was eventually applied across industries.
Today, we are at a similar inflection point with IT. As software becomes more and more integrated with hardware, the quality of both components has to be at par. If that is not the case, the quality of an integrated system will be determined by its weakest component. The consequences can be dire and expensive as recent cases show. For example, Porsche had to recall its electric car because of an error in the battery management system. Boeing had to ground the 737 MAX after a software problem in the MCAS system led to several disastrous crashes.
Software must meet the quality standards of the mechanical components it gets integrated with. The same rigor that is applied during the physical assembly process will have to be applied to the software manufacturing process. To get there, we have to roll out best practices that have proven successful in many projects in the past.
In my many decades of experience working on software quality and testing, I’ve found that the real mistakes typically happen during what we call the requirements phase. The key is to make sure you provide software engineers with complete, consistent and unambiguous requirements before they start coding. It’s like building a house. The people building the house and the architects debate, based on the blueprints, until they are all sure they’re ready. Only then do they get the materials and start building. The same kind of conversation is happening for all products. There will be design reviews, customer workshops, and all kinds of well-established reviews driven by the product owner to make sure the final version meets the market’s expectations and thus is likely to sell.
For most IT solutions, that does not happen. Instead, developers are left with vague requirements and roughly-sketched expectations. When it comes to user acceptance tests, everyone is frustrated when. the version delivered does not meet the expections. Then, through many cycles, the system is gradually improved until it can be accepted for production.
Building quality software is very much a team sport. It requires the participation of end users of the software, developers with the right skills, and quality engineers. Together they need to set up and maintain continuous automated quality assurance. Modern agile teams are set up exactly like that.
In addition, the pure software functionality needs to be fit for purpose. Today, the keyword is experience – and quality is essential to exceptional ones. A nice example of how quality is changing the perceived value of a product is the iPhone. When it entered the market a typical price for a phone was around $100. Because of the vastly superior customer experience that an iPhone provided, suddenly a price of $600 became acceptable to many consumers.
Quality helps to sell more at better price points and saves operating costs. Another good example is gaming software. A Sony PlayStation or Xbox uses complex and sophisticated software, but works to perfection. That’s because gaming companies have no choice. Why? Because children are very unforgiving. If there’s a problem, they will throw the product away or never use it again.
So we recommend that before an organization starts developing a piece of software, it asks what kind of persona it is targetting. An old or young person? Men or women, or both? Will it be a mobile app? Should it be portable to all mobile devices? Does it require internet at all times? Such basic design questions must be answered. But surprisingly, too often they are not, until much later in the process.
Our most successful clients are using software quality as a differentiator and a unique selling point. The return on investment for better quality assurance is surprisingly short — and that only factors in the operating expenses for development and day one support. If you add to this accelerated time to market, better customer experience and improved brand recognition, enhancing software quality becomes the only smart move.
As military hero William A. Foster once said: “Quality is never an accident, it is always the result of high intention, sincere effort, intelligent direction and skillful execution, it represents the wise choice of many alternatives.”
Andreas Golze is Vice President, Quality Engineering and Assurance at Cognizant.
