I have been a software engineer for most of my adult life. The good news is that software still fascinates me. We are going through an incredible period of technological innovations, which has forced the software industry to constantly change to accommodate new programming paradigms. We started with procedural programming; moved to structured, functional, event-driven, object-oriented and a host of other programming methodologies. The bad news is that software quality continues to be terrible when compared to hardware, pharmaceutical, manufacturing and other industries. . Reportedly, about 70% of software projects fail according to the Standish Report. There have been several studies by organizations like Mercer Consulting, British Computer Society, National Institute of Standards and Technology (NIST), Tata Consultancy and Association of Computing Machinery (ACM), who have attempted to estimate the cost of software failures. While these studies do not agree on the percentage of failed projects, there is general consensus that the cost is upwards of $100 billion per year.
Don't get me wrong. The evolution of software engineering has been a tremendous success. We only need to look at our computers, tablets, e-book readers, smart phones and other hand-held devices to understand how they have dramatically transformed our everyday lives, primarily because of the software applications that run on them. But that success has a darker side to it - one that is plagued with catastrophic failures. Some examples of these major software failures can be found at:
Software Hall of Shame (from IEEE article, “Why Software Fails”)
History's Worst Software Bugs (Wired)
Why haven't we learned from these failures? Why does software quality continue to be an issue even in 2012? Watts Humphrey, a senior fellow at the Software Engineering Institute at Carnegie-Mellon University, says that unrealistic construction schedules is the primary reason. He writes, "Two questions have often bothered me about software work. First, why do competent software engineers agree to completion dates when they have no idea how to meet them? Second, why do rational executives accept schedule commitments when the engineers offer no evidence that they can meet those commitments? Where software is concerned, many otherwise hardheaded executives willingly accept vague promises and incomplete plans."
Unrealistic schedules force engineers to skip quality control checks during the elaboration and construction phases of the software project. Management and business stakeholders push to deliver the software to market with little testing. The end result is usually not good. There is an old adage in software engineering, “If it doesn’t have to work, we can build it really fast.”
As software engineers, it is our primary responsibility to build software that meets specifications. There are no short cuts. A robust set of quality assurance standards together with a comprehensive quality control test plan must be part of any software project.
Samuel Prasad, PhD, PMP, PMI-ACP, CSQE
