W. Edwards Deming's 14 points for Software Development
This tip was originally submitted for our Search390 Website. But it contains insights that are applicable across the entire spectrum of software development, whether you are developing software for mainframes, for Web sites, for small computers, for client-server applications, or what have you. Developers should absorb the idea of total quality management, suited for their particular organizations, of course.
Professor W. Edwards Deming's theories are the basis for TQM (Total Quality Manangement) and ISO 9001 quality standards. Many of his pronouncements were decidedly counter-intuitive when he made them. For example, he said don't manage by expertise or past experience alone. Always measure or you'll never improve, and you'll never get beyond what you already know.
While Professor Deming's theories on quality were not in demand in post WWII United States, Japan welcomed him with open arms. The onslaught of "quality" and "affordable" cars from Japan that flummoxed our auto companies was thanks, in large part, to Deming. And you may recall the derision accorded Japan when that country's auto makers had the audacity to move past "economy" cars and take on the "luxury" auto market too. The laughter ceased rather quickly.
I have found Deming's teachings apply very well to software, not just to heavy manufacturing. Time and time again the consensus remedy or the expert's remedy failed to gain projected improvement. We would not have known this had I not insisted on measurement of improvement, if any, rather than the presumption that the problem and solution were evident.
It's worth your time to know and to understand Deming's 14 points, listed below, which I've paraphrased, where possible, to come from a commercial software developer's point of view. Enjoy!
- Create constancy of purpose toward improvement of product and
service, with the aim to become competitive and to stay in business,
and to provide jobs. Gradually increase quality rather than play
leapfrog by ignoring current bugs, instituting quick fixes and saying
"Wait until next release!"
- Adopt a new philosophy: Quality is everyone's job.
- Cease dependence on inspection to achieve quality. QA (quality
assurance) testing usually finds the problem too late. The best answer
is to design bugs out rather than retrofit fixes. If you haven't time
to do it right when will you have time to do it over?
- End the practice of awarding business on the basis of price. Instead,
minimize total cost. Move toward a single supplier for any one item, on
a long-term relationship of loyalty and trust. How can you feel secure
knowing critical components or expertise come from the lowest bidder?
- Improve constantly and forever the system of production and service,
to improve quality and productivity, and thus constantly decrease
costs. Stop the periodic purges, upheavals, methodology-of-the-month
- Institute training on the job. The quickest way to disenfranchise
staff is to give all the new neat stuff to the consultant you brought
on board for six months.
- Institute leadership. The aim of supervision should be to help people
to do a better job. Supervision of management is in need of overhaul,
as well as supervision of engineers.
- Drive out fear, so that everyone may work effectively for the
company. Of course, a low unemployment rate does this quite nicely.
- Break down barriers between departments. People in research,
development and, yes, even marketing/sales must work as a team, to
- Eliminate slogans, exhortations, and targets for the work force
asking for zero defects and new levels of productivity. Such
exhortations only create adversarial relationships, as the bulk of the
causes of low quality and low productivity belong to the system and
thus lie beyond the power of the work force. Eliminate work standards
(KLOCs, bug fix counts, etc.) among developers and support personnel.
Substitute leadership. Eliminate management by objective. Eliminate
management by numbers, numerical goals.
- Remove barriers that rob the hourly workers of their right to pride
of workmanship. Code ownership should be out of pride and not
considered punishment. The responsibility of supervisors must be
changed from sheer numbers to quality.
- Remove barriers that rob people in management and in engineering of
their right to pride of workmanship. This means, among other things,
abolishment of the annual or merit rating and of management by
- Institute a vigorous program of education and self-improvement.
- Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.
Jim Keohane (firstname.lastname@example.org) is president of New York consulting company Multi-Platforms, Inc. His company specializes in commercial software development/consulting with emphasis on cross- platform and performance issues.
This was first published in October 2000