Fast Times

James H. Burrill, 2/5/97

One of you has pointed out that I am a firm supporter of documenting the procedures that we use to develop software. Guilty, I agreed. Then, they asked "Is the industry - hardware and software - changing rapidly enough that documentation becomes a burden?" Well, I had to agree that documentation was not as much fun as coding. It's always been a burden to me. I would much rather create than describe my creations. However, the question should be "Is the documentation required by ISO 9000 cost effective when things change so fast?" I won't try to define cost effective here. But, I will try to point out what I feel is the misconception inherent in the question.

When I first started out in this business I worked on a computer that was the size of a desk. It had 16 KB of memory, typewriter IO, and a paper tape reader/punch. It wasn't very fast. We did our programming in a language called "10-4". By today's standards, 10-4 would not even qualify as an assembly language. The programming environment was a paper form designed to be used in coding 10-4 programs.

In the mid-seventies I worked on a system that filled up the better part of a 30 by 50 foot room. It supported 150 simultaneous users. We did our programming in Fortran and assembly language. The programming environment was punched cards or a line editor.

In the mid-eighties I worked on a system the size of a file cabinet. It had a graphics display and, while it could run multiple programs, it was really meant for one person. We did our programming in C. The programming environment was emacs and make.

Today I use a PC that sits in a small corner on the top of my desk. It has more compute power than any of those previous computers (though not nearly as much data streaming capability as the last two). I do my programming in C, C++, VBA, and Java. While I still use emacs, I also use Integrated Development Environments and visual programming tools.

Think of the magnitude of the changes. Computer access scheduling to batch processing to time sharing to individual workstations. Assembly language, high level languages, object-oriented languages, code generators. Even our methodologies change. Structured programming, object-oriented design, CASE tools, Groupware. We certainly are much more productive now.

We, software engineers, also make the same mistakes and have the same problems. While our tools allow us to accomplish more, we still have late projects that are over budget and full of bugs. By now we should know that no new tool or methodology will be the silver bullet. And, if past is prologue, something new is always coming.

Each new software engineering idea that flows down the pipe from the world of research and the world of the vendor is heralded as the solution to all the productivity and quality woes of software.

And each new idea, once it hits the software shop floor, dissolves into a puddle of mediocrity.

Robert L. Glass, Software Creativity, Prentice Hall, 1995.
Think about what I have just discussed. I have been talking about chisels and saws and routers. Does a power hammer obviate the need for plans? Does switching to a table saw eliminate the need to check the work? Do improvements to any of these tools remove the need to communicate?
Perfection of means and confusion of goals seem, in my opinion, to characterize our age.
Albert Einstein
What is the process a carpenter uses? It might go something like this:
  1. Talk to the customer and determine what needs to be done.
  2. Decide on how to do it, what materials and tools will be
  3. needed, and estimate the cost.
  4. Obtain the customer's agreement.
  5. Get the materials and tools together.
  6. Do the work.
  7. Check and fix the work.
  8. Convince the customer that the job was accomplished and should be paid for.
Is this much different than what we do? A carpenter certainly requires different tools, skills, and knowledge. We might go into more details such as requiring that any project plan must specify the coding conventions, the design methodology, and the review process to be used. But, fundamentally the process we use contains the same elements as the carpenter's: planning, communicating, verifying. We shouldn't confuse the plans that are developed with the process of planning.
The supplier shall establish and maintain documented procedures to control and verify the design of the product in order to ensure that the specified requirements are met.
ANSI/ISO/ASQC Q9001-1994, 4.4 Design Control
ISO 9000 doesn't require us to select a set of tools that will be used in every project. It only requires that we do the planning on what tools we think we will need for a particular project. It requires that we communicate that plan, verify that the tools are doing the job, and change the tools when that will make an improvement. ISO 9000 is concerned with human processes - not tools. And, we haven't changed in thousands of years.
Plans are nothing. Planning is everything. Dwight Eisenhower
Back to Quality Essays