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.
How are you or your team managing the failures?
The focus is in fixing the bugs as soon as possible, not in how to improve the software development process that allowed the bug progress through to production.
In the best cases: write emails to the development team or write defects catalogues in a Wiki.
Can software defects be prevented by simply logging them into some “defect tracking tool”, documenting them and providing fixes for them? How we can share lessons learned to avoid future defects?
Currently, software failures are an embarrassing subject, but we should learn from other engineering disciplines and used them as an opportunity to improve our future designs.
Idea: DRYF = Don’t Repeat Your Failures
(Jidoka in Software Development)
Lean management is based on two concepts: the elimination of “Muda”, the waste, from the production process, and “Jidoka”, the introduction of quality inside the production process and product.
In software production, the elimination of Muda received significant attention, while Jidoka has not yet been fully exploited.
For instance, Agile principles refer to concepts related with waste elimination like refactoring, YAGNI, the simplest that works, DRY, etc.
(Jidoka in Software Development)
TPS history and about lean thinking:
Short after WWII Taiichi Ohno and Shigeo Shingeo revolutionized the Toyota Production System with the idea of lean production (Ohno 1988). Because of their visible and tangible success, their ideas were successfully exported from Japan to the Western world.
The Toyota Production System advises to eliminate from the production process all activities that do not produce value to the customer (i.e., Muda).
The philosophy to focus on customer satisfaction as a wayto increase flexibility came back in the ’90 with the book “Lean Thinking” by Womack and Jones (1996). Lean Thinking brought the lean idea into new industries such as the pharmaceutical industry (Petrillo 2007) and software development (Poppendieck and Poppendieck 2006). Agile methods are a group software development