When faced with a problem that needs to be solved with precision, no one would even consider not measuring carefully two, maybe even three times. Consider a carpenter building a bookcase the full length and height of a wall – he has absolutely no room to spare, he must be precise in the angles he cuts. Consider a seamstress tailoring a wedding dress. She cannot afford to miss-measure and risk ruining the bride’s big day. How about a doctor preparing to amputate an arm or leg? The amputee most certainly doesn’t want the doctor to give a haphazard measurement such as “Well I think right about there ought to do it!” This saying is true in many professions, not the least of which in the technology field.
Technology fields are fields of science. No good scientist would ever consider flying by the seat of their pants, most especially not when proving a hypothesis. In the computing industry, when we sit down to our computers to solve wicked problems, we effectively take off our cap and jacket, put on a lab coat, and go about forming and proving hypotheses. Sometimes however, if not careful, people are tempted to start performing experiments before forming a hypothesis. This is quite nearly as dangerous as self-diagnosing a medical condition via Yahoo! Answers.
I.T. professionals must remember their job requires a scientific and analytical approach to solving problems. Companies that hire I.T. professionals must remember that getting to the bottom of a problem is a process and rushing that process or trying to self-diagnose the answer to the problem will most often result in an experiment blowing up in someone’s face.
So what does that process look like?
First, identify the problem. Ask some research questions:
- How is the problem reproduced?
- Who reported the problem?
- Are there any errors being indicated by the system? If so, are any of those errors false negatives or alternatively is any one potentially the root problem?
Second, list some hypotheses (don’t do any experiments yet!) and gather data in preparation for experimentation. Data will be things like:
- What is the average amount of time for X to run?
- What is the average number of times X occurs?
- What is the average size of X?
- How often or when does the problem occur?
- Is the problem/measurement the same regardless of where or who or when?
Third, based on the problem definition and the baseline metrics taken, begin proving or disproving your hypothesis with methodical changes (your experiments). After each change (sometimes after each step in making the change) re-measure and compare to the baseline metrics to verify if the change had an effect.
By following a methodical process to problem solving, the I.T. professional ensures that the correct problem and its root cause is found rather than taking a shoot first and ask questions later approach that may or may not actually solve the problem. At the end of the process, they are armed with information and real, honest proofs to show for their work and of course the solution to the problem.