This three-part series written by Peter Antman takes a journey through the evolution of quality assurance, takes a look at the current state of "quality" in the software industry and explains what we all must do to raise the standards of quality throughout the technological world. In this post, Peter looks back on the story of one of the great innovators of the last century.
It may seem old school, but every now and then I'll start pristine Emacs and hack away on a piece of Java. I mainly do this for small stuff, since starting or setting up Eclipse takes a little bit too long for such minor projects. Even so, I don't do this as often as I used to.
Why? I guess you know the answer: Nowadays, even the thought of not having instant feedback on syntactical and semantical correctness makes me shudder. It’s like coding in the dark. Incremental compilation is one of those great innovations that have increased the quality of our work.
I can already hear the objections: "Incremental compilation is just a convenience! The quality is guaranteed anyway, since it eventually will not compile when doing a real build - at least when developing in Java or other compiled languages."
And that is true, but only if you look at the coding process from a global perspective.
If you zoom in, if you look at each step separately, such as write-build-run, it’s clear that without instant feedback (like incremental compile) the risk goes up that you will produce stuff with quality defects during the write step, broken code that is, which will only surface during the build or run step. I expect everyone will agree that this is bad.
One fundamental aspect of quality is fast and accurate feedback. Take a painter, how would the quality of paintings be if a painter could not see what he or she was doing. What about a carpenter? As soon as you start separating the act of producing something from the possibility to understand and control the quality aspect of the result, as in most processes where parts of the works are done by machines instead of humans, the quality aspect will become a major issue. This means we need to find ways to help us achieve quality in those situations.
A Brief History of Quality
One of the early innovators in this domain was a guy named Toyoda Sakichi, praised as the “great genius” by Taiichi Ohno, innovator of the Toyota Production System, in the west called “Lean Manufacturing.”
Yes, Sakichi founded the company Toyota. No, he did not make cars.
Sakichi was raised in a village where every house had a hand-weaving machine. Hand-weaving is a very time consuming process, but it is also a process where you get instant feedback if something fails, such as when a thread brakes. Cloth weaved by hand is therefore potentially of very high quality, but also expensive.
That's right, Toyota was actually founded as a spinning and weaving company.
Wanting to automate the weaving process, Sakichi created his first power-driven loom in 1897. But he soon realized the fundamental problem with this kind of automation: the lack of a human getting instant feedback on quality problems. What happens when a thread brakes in an automatic loom? Nothing. Or to be more correct, a cloth of lesser quality is produced, which can only be handled in two ways: manual inspection or fault reports from the end users.
If hand-weaving is expensive, chasing quality problems is also expensive. The longer the time has passed since the quality problem occurred the more expensive it will be to both find and fix the problem. Either you have to have an expensive QA process where you manually try to find defects, or you will have dissatisfied customers and the cost of reimbursing them.
But what is even more troublesome is the hidden cost: If a quality problem is not discovered when it occurs, it is extremely costly or even impossible to find the source of the quality problem. If you don't find the root cause of the problem, your process will continue to produce defects.
It took Sakichi almost 25 years to solve the problem. He finally did it by inventing a loom that could automatically stop when it detected a broken thread. It took the software industry more than 25 years to come up with incremental compile, the first little step towards instant feedback on our work, and it's not even a true stop-the-line mechanism. You can continue producing faulty stuff if you like, but at least its makes it possible to stop and correct your work instantly, close to the source of error.
I hope that, in the future, we'll see the concept of incremental feedback expanded to also include incremental testing. There’s already tools available that will only run tests covering the particular code you have changed. Lets take that to the next level and beyond: tests are run incrementally as you type, even the integrations tests!
While waiting on the almost artistic feedback loops that would give us, we can continue to learn from Toyota. How do they handle situations where the machines can not detect defects? This conversation will be the subject of our next post.
About the author:
Peter Antman has a passion for improving how we build software together. Currently he is coaching companies doing agile transformations as a consultant at Crisp. He has a background as Head of Development of Atex Polopoly where he enjoyed building large scale test environments. He was also one of the early comitters to the JBoss project.