Legacies

We have all inherited various legacies–documents, systems, processes or programs–from predecessors or colleagues. Taking over work requires that you learn what the other person did, how they did it and what assumptions were built in. This is a sometimes painful task, as you take ‘ownership’ of the item. Any large, complex operation requires co-operative work between many people–and there are few more complex operations than a mine! In such an operation, there are many legacy items, passed from person to person, and sometimes coming back to haunt the same person years later.

While troubleshooting at a mill once, I encountered some apparently insoluble problems. Flow rates could not be set correctly, chemical dosages did not match settings, and results bore no apparent relation to expectations. I went back to basics, using a thermometer (my favourite ‘temperature sensor’), and a bucket and a stop watch (my favourite type of ‘flow meter’) to survey flows throughout the mill. The results were amazing, as they did not match the DCS settings!

Using my very basic ‘instrumentation’, we were able to bring the process under control quickly. In later reviewing the logic in the DCS, we found that most of the expected calculations and control loops were in place, but many did not control anything. A large number of processes were controlled by set figures, unaffected by the operators’ settings. We tracked down a programmer involved in setting up the original control logic. He told us that everyone had been under great pressure to get the mill running, and the programmers could not get answers to their questions. So they made a few assumptions (i.e., all chemicals have a density of 1.0 g/cm3; temperature is unimportant), and they set several of the control parameters to constants, as the required calculations were too complex to work out in the time available. Up to a point they were successful, as nobody noticed for over a year!

At another location, I had worked with the mill over years pursuing various changes to the process. Now, with a different set of personnel, we started a different project though with some similarities to the previous work. One of the engineers sent me a spreadsheet that he thought might be useful in monitoring a planned trial. It was a fairly complex spreadsheet, allowing the calculation and printout of tables for dosage control, and easy recording of results with the automated generation of graphs. I complimented the engineer on a fine piece of work. He just told me to look at the author’s name. It was my own spreadsheet from the project, 10 years before!

The above are two opposite examples: one of a legacy of hasty work coming back to haunt those who inherit it a year or more later; the other of good work producing a document with lasting value. Either result could have occurred in either situation. Prior to our current level of technology, even 20 years ago, these situations would not occur, as such legacies were much less likely. Now, the logic installed with a DCS will remain in place until the next control system is installed. Even upgrades will often inherit the same logic–possibly carrying the original errors even further.

It does not have to be that way. A good piece of work is also a legacy, carried into the future even further as it will be preserved by the deliberate efforts of those who have found it useful.

Each of us has the choice with every project we do: work on each one as if preparing something that you will be able to use 10 years from now, and who knows, maybe you will.

Freelance writer Dan Davies can be reached at dan.davies@shaw.ca.