It was a restaurant my wife and I had passed many times, and we had always told each other, "We must try them some day." When we finally tried them, we were pleasantly surprised. The food, the service, the atmosphere, even the price were great! "This will be a regular stop for us," we agreed. But on our third visit, we had to send our food back twice. Another time, we waited nearly an hour for our order. Then, some time later, we were seated at a table that was not clean. Most of the time, things were great. But as we experienced sporadic problems, we visited that place less and less often.
Why is it that a business can do so well some of the time and mess up so badly at other times? What causes this inconsistency? If we could have taken a peek behind the scenes at that unnamed restaurant, what would we have found?
Inconsistency in quality of food, service, products, software (of anything) is almost always caused by inconsistency in the way those things are done. Poorly prepared food in a restaurant is often the result of a cook who in unfamiliar with the procedures for making certain dishes. A dirty table will result from the bus-person taking shortcuts.
In the same way, quality problems in software have their genesis in some sort of inconsistency. For example:
· When good project planning processes are skipped, developers are often required to do too much work too quickly, and end up making mistakes along the way.
· When project-staffing processes are not adhered to, inexperienced programmers can be pressed to do jobs that require skills or knowledge they lack, resulting in errors of judgment.
· When software design methods are used inconsistently, systems are sometimes poorly engineered.
· When developers are inconsistent in their coding practices, many defects can be injected.
· When configuration management procedures are not followed, good technical work may be lost, and must be replaced in a hurry.
Because the quality of our software is so closely tied to the consistency with which our processes are followed, it stands to reason that this should be among the first places that we look when trying to solve our quality problems. Unfortunately, that is easier said than done.
Suppose that your organization has a problem with interfaces among components not working correctly. During integration and system testing, you end up spending inordinate amounts of time diagnosing and fixing these interface defects. So, where do you look to find the offending process? Which of your processes should you suspect? It may be the way you do the architectural design for the system. Possibly, the component designers struggle with translating the system architecture into workable designs. It could also be a coding issue. On the other hand, it may also be that the architecture reviews (or design reviews or code reviews) are not effective. Then again, maybe it is a matter of training the staff to be competent with the technologies and techniques they are using. Perhaps the problem lies in the ways that project-staffing decisions are made. The list goes on and on.
This sort of a reactive approach to our processes is terribly inefficient, so we want to avoid taking this sort of reactive approach to quality problems. It is an inefficient approach for two reasons. First, you wait to take any action until there is problem, which means you have incurred the waste and rework inherent in defective systems. Second, as we observed above, diagnosing the actual root cause of the problem is not an easy task. It will require significant investigation to get to the root of the matter. All of this effort is being expended before you have taken the first step toward actually fixing the problem!
The alternative to a reactive approach is a proactive approach. That is, understand and monitor the effectiveness of your processes so you can avoid process-related problems. Make sure that your processes are working well and used consistently, and you can avoid much waste and rework. This proactive approach is not a new concept. It has been the foundation of quality programs for decades, ever since the 1930's and 40's, when Dr. W.