By Sam Malek, CTO / Co-Founder of Transvive Inc., and CISQ Member

If you have been following the news these days, you probably heard about the recall of some General Motors cars because of an ignition switch issue. It is estimated to be 2.6 million cars (1) and will cost around $400 million (2), which is roughly $166 per vehicle. This price is significantly expensive for a 57 cent part that could have been easily replaced on the assembly line.

As we enter the third wave of the industrial revolution (Toffler), where information technology is starting to dominate major parts of everyday life, software is becoming a critical component of day-to-day activities: from the coffee machine that might be running a small piece of code to the control unit that governs vehicles, and everything else in between. 

However, these days with the overflow of news about applications that have made millions – even billions – of dollars for their developers, the stories we hear about the development life cycle does not necessarily highlight the quality aspect of any software development cycle. Even in some recent documentaries and blog articles, the software development cycle is portrayed as a mad rush to get software out of the door without proper attention to its quality.

The case for higher software quality becomes even more important when an application is touching a critical aspect of our daily living. For example, vehicle drivers do not expect the onboard instrumentation to shutdown or crash due to a software malfunction – especially while driving on a highway.

While the origins of software defects are many (including design defects, requirements defects, coding defects, etc.), coding defects present the highest percentage of software defects when measured as a number of defects per a functional point. Dr. Capers Jones estimates that about 35% of any software application’s defects are attributed to code defects (3). These code defects can be easily detected and fixed while software is being manufactured, and the cost would be relatively very small when compared to fixing them later – as we found out with GM’s ignition switch issue.

The process of developing software is maturing. In the past, the focus was on extensive testing in multiple areas such as user acceptance testing, regression testing, and scalability testing. Today there are quality tools that enable early detection of software coding, structural, security and reliability defects during the manufacturing process. These tools can highlight potential issues within the software, thereby reducing the risk of fixing defects at later stages.

Late inspection of software can cause rework and expose technical debt, potentially making the cost of fixing defects or the cost of a change anywhere from 40 to 100 times greater than the cost of fixing those very same defects when they were first created (Boehm, 2004). This alone can make the case for implementing early quality monitoring tools.

Early inspection is not new. In fact it has been an integral part of the Industrial Revolution especially in the 1980’s through the work of the late W. Edwards Deming, who was well known at that time as the father of quality.

While software practices such as waterfall methodologies have been focusing more on detection of defects in later cycles, we can learn from the quality revolution to harness the “Mistake Proofing” technique for automatically preventing defects from happening. This is called “Poka Yoke” – a Japanese term which means “mistake proofing”. The purpose of mistake proofing is to prevent defects or unnecessary work later on before or during the final product is within the hands of its users.

Over the past few years, we have seen many IT shops implement proactive diagnosis only on the operational side of IT, such as proactive network and security monitoring. A smaller number of development shops have also integrated proactive defect tracking and fixing within software application development. As a result, these shops deliver the highest possible quality work and have the highest customer satisfaction.

If you look at the history of auto manufacturing which began in the 1890’s within the United States, it took almost 90 years for the industry to start learning about the true meaning of Total Quality – although it was already implemented in other parts of the world and especially in Japan- after the rise of the import automobiles market share. The “Key” question is, how many years will the software industry take to realize the same conclusion?

About the Author

Sam Malek is CTO and Co-Founder of Transvive Inc., an application modernization consulting firm. Sam has a track record of aligning business and IT strategies and a passion for helping organizations transform, improve service delivery and achieve operational excellence. Sam has been working with enterprises to design and implement strategies to deliver innovative solutions to complex problems in the Enterprise Architecture and Application Portfolio Management areas, specifically the field of application modernization.

References

(1)    GM ignition switch probe finds misjudgment but no conspiracy-http://www.cbc.ca/news/business/gm-ignition-switch-probe-finds-misjudgment-but-no-conspiracy-1.2664803

(2)    Chevy Aveo Recall Brings GM Total To 13.8 Million-  http://washington.cbslocal.com/2014/05/21/chevy-aveo-recall-brings-gm-recall-total-to-13-8-million/

(3)    SOFTWARE DEFECT ORIGINS AND REMOVAL METHODS –http://namcookanalytics.com/software-defect-origins-and-removal-methods/