A friend who works in fashion design told me an interesting story. She was doing a final project in art school and had developed a complex outfit. Her customer for this clothing had been consulted extensively. Many questions were asked and color and material samples were presented. The customer chose their preferred materials and colors. Sketches were created and presented to confirm the appearance of this clothing. Approval was given by the customer.
Now much work began on the part of the design team. They had to work out all of the cuts, folds, seams, and sizes. No detail was too small. Excruciating attention was paid to each stitch, each fastener, and every bead and decoration. The physical production of the outfit required painstaking effort to follow the design exactly. Hundreds of hours were spent producing the single sample.
Finally, came the day of the finished product presentation and grading. The customer studied the outfit carefully, then said, “It looks great, but can we change this color? I think I want something different.” The customer wanted to change the colors after the product was sewn.
My first reaction to this tale implied brains exploding and physical violence should have resulted. Later, the more I thought about this, the more it made sense to me in a strange way.
My friend George once said to me, “Everything is trivial to the person who doesn’t have to do it.” Many engineering projects are like the dress described above. The customer is heavily involved in creating a product specification. This can be a difficult, brutal process.
The customer gets asked endless questions and maybe cannot be faulted for thinking, “Hey, I’m doing all the heavy lifting here, telling you exactly how this should be done.” We know that the customer is not really figuring out how something gets done, but is only describing the surface of the problem and requesting some specific end results.
Most important, the process of designing (planning, implementing, debugging, analyzing--and the many repetitive loops of this process) is totally invisible to that customer. They cannot see anything happening so they can easily believe that they did the hard part. Most importantly, they cannot conceive of the time required to do all of these steps. They especially cannot understand how much of the development process must be repeated given a single change to one fundamental specification.
There are certainly some things we can do to attempt to mitigate late changes in a specification. Using programmability (processors, software, and programmable logic) are some of the modern tactics we use to give ourselves flexibility. Yet all too often, we have just pushed the problem into somebody else’s domain. Now it is software development, quality assurance, or regulatory test groups that are told that they need to suddenly adjust to a new set of inputs for their work.
The horrifying part is that I sometimes find that I am the guy assuming that everybody else can change the color after the fabric is sewn. I am the guy who made stupid timeline assumptions because I simply did not understand the other guy’s task. But that is me.
You wouldn’t do that, would you?