Trouble Shooting - The Method Behind the Madness

For relatively simple problems, trouble shooting a process can often be done on the fly using a little common sense, which, if we formalize it a bit, is actually an entwined sequence of inductive and deductive inferences that are often made without our thinking much about it.

But what are these inductive and deductive inferences you might ask?

Well, an Inductive inference starts with observations of a thing or process and arrives at a general conclusion about it. For example, if I develop a plate for 30 seconds and discover that my shadow areas are noisy and fogged, then I develop another plate for 15 seconds and see that my shadow areas are crisp and clear, then I develop again for 30 seconds and this time notice that my shadow areas that are noisy and fogged, then I develop fourth plate for 30 seconds and my shadow areas are again noisy and fogged. I can conclude that extending my development times to 30 seconds produces noisy fogged shadow areas. That is induction: reasoning that moves from particular experiences to general truths.

Deductive inferences on the other hand, move in the opposite direction, they start with general knowledge about a thing or process and then predict a specific observation. For example, if we know that our collodion film is insensitive to low energy wavelengths longer than 500 nm and we also know that the wavelength of red light falls in the neighborhood of 650nm (considerably longer than 500nm). We can deduce that red light will not trigger the halides or produce fogging of the film when it’s developed, and that we can utilize red light for safe illumination in the darkroom.

Deductive reasoning requires strong knowledge of the subject. While Inductive reasoning requires a constant awareness of the process to pick up clues and identify potential relationships between various events (ones that we may, or may not, be expecting). The successful practitioner is both knowledgeable and mindful.

Other aspects of trouble shooting that are useful to note include one’s general attitude. To successfully troubleshoot a problem it’s helpful to be in a relaxed state of mind. This allows you to be more perceptive of the environment you’re in, and the process you’re examining. Being hurried, impatient, or trying to force the process usually doesn’t work well.

Clearing your mind and being receptive to new information is also extremely useful. Walking into a trouble shooting session with a preconceived answer already formed in your mind is a surefire way to have the process misfire. Be humble. Be the novice. Be the student. Watch and learn. Be receptive and allow Nature to instruct you in her ways.

Physical comfort is also important. If you’ve ever tried to think clearly when you’re cold or hungry, you know it usually doesn’t work well. Your attention is elsewhere. It’s hard to trouble shoot a problem if you’re distracted and thinking of something else.

Patience. Sometimes you’ll need to take a deep breath and start over. Or repeat a particular experiment. Or wait days, or weeks, or months, or years, to discover a pattern in a particular mode of failure that only occurs intermittently. These are the tough ones. Patience, and attention over time, are your best resource in these cases.

When a troubleshooting problem is big enough to elude a common sense approach, where the chains of inductive and deductive reasoning are short or singular, then it’s time to break out the full blown, formalized, scientific method. Though that may sound intimidating, at it’s core, it’s really only 6 steps:

1 - Statement of the problem

2 - Hypothesis as to the cause of the problem

3 - Experiments designed to test each hypothesis

4 - Predicted results of the experiments

5 - Observed results of the experiments

6 - Conclusions from the results of the experiments

For this you’ll need a lab notebook where everything gets written down formally. This may seem a little tedious, but this is your all important trail of breadcrumbs that’ll prevent you from getting lost. You’ll always know where you’ve been, where you are, and where you want to go. If you don’t keep a notebook, it’s all to easy to get lost in the forest of complexity and forget what you know and what you don’t know, as nature tries to fool you into thinking you know something you really don’t.

The first entry in your notebook is a statement of the problem. The main skill here is to state nothing more than you are absolutely positive you know about the problem. It’s better to write something like “Problem to solve: blotchy areas on the image.” than to write “Problem to solve: bad developer pours” since, to begin with, we really don’t know for sure that the problem is caused by a bad developer pour at all. If you suspect it is the developer pour, then the correct way to write this in the notebook is: “Problem to solve: Blotchy areas on image” followed by “Hypothesis 1: the problem lies in the developer pour.” This careful approach to documenting the first statements keeps you from taking a wrong turn which might cause untold hours of extra work or even stop you completely.

Step 3 and 4 work together. This requires a little imagination to plan an experiment that will change only one variable in the process that you suspect might be related to the problem. As you do this, try to predict the outcome that you would expect to find. This is where deduction comes into play, using general knowledge to predict specific outcomes.

Step 5 documents the results of the experiment to clarify what actually happened and avoid jumping to erroneous conclusions. If you encounter unexpected results, repeat the experiment a few times to see if you get consistent results, and if a pattern emerges, you can use inductive reasoning to reach a conclusion.

Finally, step 6 formalizes the conclusions you’ve reached based on the experimental results you’ve observed. Quite often these conclusions will suggest further experiments to refine the conclusions already reached.

By asking the right questions, and choosing the right tests, and drawing the right conclusions, you’ll work your way down the logical structure of the collodion process until you’ve found the cause (or causes) of the failure in question, at which point you can change them so they no longer cause the failure.