Page 60 - Practical Control Engineering a Guide for Engineers, Managers, and Practitioners

Introduction to Developing Control Algorithms 35

This task of simulation at first looks incredibly difficult but it
is my position (a minority one, at best) that once the engineer
takes the time and trouble to conceptualize the process and con-
trol system as shown in Fig. 2-12, she will be able to construct an
approximation of the process that is quite useful for testing the
control system. It will take time, effort, and resources but the cost
will be minuscule compared to the cost of using the process to
test the control system.

2-6 Documentation and Indispensability
Consider the following scene. My manager /boss stops by my cubicle I
office and says, "Dave, you are doing an absolutely great job on the
project. Your contribution is playing a critical part in the success that
we are enjoying. You have become indispensable! I will give you a
month to thoroughly and clearly document what you have done or I
will have to fire you."
That conversation has never taken place with me and my boss
nor have I ever heard of it taking place with a coworker. How-
ever, I have seen innumerable instances where it should have
taken place.
Much folklore and fear has developed around undocumented
equipment, algorithms, and methods that at one time, at least,
were successful. Many of these "successes" were used with rev-
erence long after they had lost their effectiveness simply because
no one knew how or why they really worked. Therefore, they
were not improved, adapted, or replaced out of ignorance (and
the incompetence of the original manager who did not demand
documentation).
Documentation is usually abhorred by engineers until the time
comes to solve a problem associated with an undocumented piece of
equipment or algorithm (after a call-in at 2:00A.M.). Many companies
have documentation czars who legislate cumbersome structures. This
usually extinguishes any creativity or enjoyment on the part of the
person best qualified to write the document. Worse yet are the docu-
mentation writers who almost always haven't an ounce of technical
competence. I have always thought that the person who did the work
should document it in any format she liked as long as it had content
and clarity. Finally, I have always thought the manager should take a
few moments to peruse the document to see if it, in fact, has content
and clarity.
I have no other advice other than to ask, "How many managers
do you know that lost a promotion because they had their engineers
spend too much time on documentation?" ... or ... "How many
times have you been in a troubleshooting situation where even a
snippet of verbiage would have been helpful?"