Maybe we don't need ISO 9000. But even if we don't need ISO 9000 now, maybe we should want it. Let me try to explain to you why I am interested in ISO 9000. I have been developing software for 34 years. After all that time, I am a still a low-to-medium-falutin' programmer.
Organizationally speaking, a low-falutin' programmer is a loner. That's not necessarily bad. Give a low-falutin' type, a low-falutin' job, and it will get done quickly. [...]My most successful project was the APL for NOS/VE system developed for the Control Data Corporation. Two other people worked on it with me. It consisted of approximately 125,000 lines of Cybil (extended Pascal). We had well defined requirements: the APL language definition, and competitive performance measures. We wrote a detailed design specification. We wrote the reference manual. We split the project into sections with well defined interfaces. One person reviewed every line of code in that system, modified the places where interfaces where inconsistent, and performed the integration testing.Organizationally, a medium-falutin' programmer is one who can work in a group. You need these folks to tackle the medium-to-high-falutin' problems. Once a job gets too big to be handled by one person, communication skills become important. Programming skills are also important but less so. [...]
A high-falutin' programmer is one who can work on projects that require multiple groups. Here is where the management becomes more important than the technology [...]. You need folks who know the technology well enough but don't have to actually write code to feel fulfilled. These types sublimate their technical urges by helping others get the job done. I have never seen a large project succeed without a serious complement of good technical managers. [...]
P.J. Plauger, The Falutin' Index, Embedded Systems Programming, May 1992, pp. 88-92.
There were two major problems: the hardware didn't exist when the project started and neither did a mature Cybil compiler. We used simulators and wrote copious memos to the compiler project. Even with the problems we finished ahead of schedule. Control Data received a robust, competitive APL system that was ready before the hardware.
What was the key ingredient in the success? This was years before ISO 9000 existed so we obviously didn't use it. We did have a process but it wasn't written down; it was in my head. We had good people. But, even more important was that we had nearly perfect communication: a small group, well defined requirements, one person who was able to check all of the details, and a way of measuring our closeness to the goal. The resulting system was a quality product because the size of the project was such that one person could find and fix most problems before testing. It was a low-to-medium-falutin' project.
I believe that our company's projects are moving from the low-to-middle-falutin' to the medium-to-high-falutin' range. In this range, one person can't handle all the details. In this range, one team cannot do the complete job. In this range, multiple groups must work in concert to reach the goal. In this range, communication becomes paramount.
There are many objects of great value to man which cannot be attained by unconnected individuals, but must be attained, if at all, by association.Rework increases when communication is faulty. And, of course, the cost of rework is a function of the complexity of the project. Because our project falutin' index (i.e., the project complexity) is rising, we need more powerful communication tools. ISO 9000 is a more powerful communication tool. As such, it is relevant for middle-to-high falutin' projects and the future our company.Daniel Webster
Daniel Webster