This is how Peter Antman in his short eBook Stop The Line describes a bug.
It happened that I’ve read his book a few years ago, but opening it again these days, I found it as confirmation of the efforts doing lately in my organization. Peter outlines the necessity of short feedback loops, testing code as soon as it is written and verifying it as frequently as possible.
The book presents the roots of the automation process started a hundred years ago by Sakichi Toyoda- years before Toyota became an automotive company. Automation with human touch was the aim.
The aim to build quality in is the core of the famous Toyota Production System. It is called Jidoka (autonomation), i.e. automation with a human touch, which is a process of bringing the human detection in discovering quality problems when
they appear. Every worker in his reach has an alarm button (called andon) to signal any abnormality, problem or a quality issue. Such an act may bring the whole production to stop – literary.
Now, compare this to the process of software creation. We have a number of tools to speed up the coding and testing, like syntax and semantics instant checkers, automatic build, automatic tests… continuous integration (CI).
How often do we stop all developers when build is broken and CI tests fail?
A CI failure is not really a halt in the process, it is rather a call for an action, a request to investigate what went wrong and WHY. With the CI, we have a mechanism to create the CULTURE (see the post about culture) of learning and thinking about quality.
As Peter says:
If you – as a developer, as a manager or as a company – are not prepared to change the culture and, at least initially, pay the price of stopping the work and start chasing defects, I would question the value of having automated continuous integration tests. It’s even worse than that. If you have a continuous integration environment that is frequently (or always) red and you don’t stop the line, the system will decline over time. Each instance that the line
is not stopped will result in a push for producing more bugs.
Perhaps in the future we will invent a new paradigm of creating faults-free software when we just specify our wishes, or our thoughts and a 3D hologram will present the solution/product in front of us.
Hmm, not a bad idea – such a pity I shared it publicly…
However, till then, try to follow the practice which is holding now for a hundred years… and gives results. Give me your thought on this – I will HIGHLY appreciate them!