2001
Here is a wonderful story, published in ACM Software Engineering Notes.
Sometime in the 80s, the story's author took charge of a software development shop in Bulgaria. He found that the group was producing low quality software and spending large amounts of time on bug fixing. Nobody on the team seemed to think this was a problem; this was just the way things were.
The boss instituted a program of quality measurement. He had data collected and charts posted. The measurement process, the attention paid by management, and the amount of labor this process took got the team's attention. They realized that they had a problem.
Finally one day, the team leaders came to the boss and said, "We realize we have a quality problem. But these charts and measurements are not solving the problem. Let us change our process and take measures to produce better code." That was the beginning of a transformation of the group's output.
At the time I read the story, Bulgaria was known in the USA mainly as a source of computer viruses. But this story really struck me. I called people's attention to it and said, "the Bulgarians understand this. Why don't we?"
The lessons I drew from the story were
Measurement is an important tool. People pay attention to what's measured.
Measurement is not quality improvement.
Quality improvement cannot be forced; the troops should drive it.
Here is the citation:
Copyright (c) 2001 by Tom Van Vleck