Fixing All The Bugs Won’t Solve All The Problems – Deming’s Path Of Frustration
jeffpsherman
A program of improvement sets off with enthusiasm, exhortations, revival meetings, posts, pledges. Quality becomes a religion. Quality as measured by results of inspection at final audit shows at first dramatic improvement, better and better by the month. Everyone expects the path of improvement to continue along the dotted line.
Instead, success grinds to a halt. At best, the curve levels off. It may even turn upward. Despondence sets in. The management naturally become worried. They plead, beg, beseech, implore, pray, entreat, supplicate heads of the organizations involved in production and assembly, with taunts, harassment, threads, based on the awful truth that if there be not substantial improvement, and soon, we shall be out of business.
W. Edwards Deming, Out of the crisis, Page 276
In software, as in manufacturing, some problems occur due to bugs or “special causes”, and some are “common cause” due to the nature of the system’s design and implementation. Fixing bugs is removing special causes. Removing bugs greatly improves software quality, but it won’t impact “common cause” issues.
Some “common cause” software performance issues I have encountered:
The software is “in the cloud”, but really it is in one data center in the US. As a result the software is slow and laggy for customers in Europe and Asia.
The software runs slowly because the hardware is underprovisioned.
The software runs slowly because large amounts of unnecessary data are being sent to the users.
The software runs slowly because of inefficient data access patterns.
Even with no bugs, “common cause” issues can result in low quality software.
The way off of Deming’s Path Of Frustration is to attack system design and implementation issues with the same fervor used to fight bugs.
