Success through Failure in Software Development: Autonomation using Aspect-Oriented Poka-Yokes
Unfortunately, the software products are shipped with very high error rates in comparison with other engineering artifacts.
The inevitable human mistakes, coupled with the steadily growing complexity of software, could explain the prevalence of mistakes in software, in no way the embarrassing number of these mistakes which are allowed to reach the customer, turning them into defects.
Few products of any type other than software are shipped with such high levels of errors.
The same errors appear again and again in different projects.
Failure to learn from mistakes has consistently been a major obstacle to improving IT project management. As Boddie wrote in 1987:
We talk about software engineering but reject one of the most basic engineering practices: identifying and learning from our mistakes. Errors made while building one system appear in the next one. What we need to remember is the attention given to failures in the more established branches of engineering. In software projects, as in bridge building, a successful effort can do little more than affirm that the tools and methods used were appropriate for the task. By the same token, failed projects need more than explanation or rationalization if they are to teach any lessons.
The main thesis of the book (To Engineer is Human: The Role of Failure in Successful Design) is that engineering failures are one of the best ways to learn how to improve and the mistakes of predecessors help improve in the future.
I believe that the concept of failure is central to understanding engineering, for engineering design has its first and foremost objective the obviation of failure.
The lessons learned from these disasters can do more to advance engineering knowledge than all the successful machines and structure in the world.
Petroski use the history of bridge failures to illustrate how we have learned, or neglected to learn, from failurs of engineering practice. The message is universal and reach well beyond engineering.
Given the faults of human nature, coupled with the complexity of the design of everything, from lectures to bridges, it behooves us to beware of the lure of success and listen to the lessons of failure. — Success Through Failure: The Paradox of Design.
Engineers learn from past mistakes and failures. It might even be postulated that engineers and the engineering profession have a duty or responsibility to do so, although this duty is not always spelled out in engineering codes of ethics.
The engineering community often considers the study of such a major collapse as an opportunity to correct and ipmrove on future design.
This is in stark contrast with accident investigations in the aeronautics industry. Open public investigations and voluntary sharing of information is part of the culture.
Construction and aircraft industries publish their mistakes so lessons can be learned.
There are innumerable sources reporting engineering disasters like Tahoma bridge collapse, etc. However, except few exceptions (Writing Solid Code), there are no equivalent references in the software industry. Neither the more popular and acclaimed books about the code of conduct for professional programmers (The Clean Coder: A code of conduct for professional programmers, The Pragmatic Programmer: from journeyman to master) refer a word about the practice of learning from failure.