I’ve spent a good deal of my programming life “spinning my wheels.”
I don’t like to admit it, but I have spent countless hours trying to solve problems I didn’t fully understand.
When you sit there trying to fix a defect or solve a programming problem without first reproducing it you are like a bicycle thief hopelessly spinning the dials of a combination bike lock hoping to stumble upon that magical combination.
It is a common ailment after all
Don’t worry you and I are not alone, many programmers share the same kindred spirit of overeager rambunctiousness of trying to solve problems before they know what they fully are.
It is perhaps ones of the greatest killers of productivity and conflagration of the nerves of programmers both experienced and in-experienced.
I’ve learned this lesson a dozen times, but I learned it again this week as I was working with Jesse Taber. We recently instituted a remote pair programming program at my work, and I had the opportunity to pair up with Jesse this week.
See Jesse is the kind of programmer that pretty much always reproduces a problem before working on it. I thought I was pretty good at doing this and insisting it be done, but after working with Jesse I found that I tend to be a little more lazy in this area than I should.
It seems pretty basic, but most of us don’t do it
Most of us tend to jump right into a problem. Dive right into the code without completely understanding what we are up against.
I don’t know how many times I have attempted to solve a problem only to find that the actual problem was not reproducible at all.
A decent majority of problems that we try to solve either are not problems at all or are not anywhere close to the description of the problem we had been given.
I’ve definitely learned that taking that hour of time upfront to properly set up your environment and actually reproduce the problem shaves many hours off the time it takes to solve the problem and verify your solution actually works.
Sometimes problems can solve themselves
It is amazing how when you follow this simple advice problems have the seeming ability to solve themselves.
I’ve found many times in working on a difficult problem that the very act of the reproduction of the problem points to the actual cause.
When you think about it, it makes perfect sense. In order to reproduce a problem, you must cause the problem. If you have caused the problem, you may be able to identify the particular thing you did that caused it.
Sometimes it isn’t that easy, but reproducing the problem is still a great place to start. After I have reproduced a problem, I often find that I can divide and conquer that problem by breaking it into sub-problems.
This technique is very similar to basic troubleshooting. We follow steps that go something like this:
- Reproduce the original problem
- Break apart the problem by determining if any aspects or symptoms of the problem that was recreated can be recreated in isolation
- Once we have a small enough problem to solve, start taking away steps and elements of the recreation of the problem until we have the minimum set of of criteria required to create the problem
- Come up with a hypothesis of the cause of the problem (not the solution), change the cause in the simplest way possible to prove or disprove the hypothesis (many times this will not involve changing any code yet)
Let us make a pact
Let’s hold ourselves to a solemn vow of never again trying to solve a problem before we can reproduce it.
Don’t just take someone’s word for it anymore. Stick your head in the sand like an ostrich and refuse to believe there is a problem until you can see it for yourself.
What do you think? Have you ever tried to solve a problem only to find it does exist? Have you wasted hours of time trying to solve the wrong problem or randomly twiddling bits?
Oh, and if you are in QA or ever write up a defect. This pertains to you also, because you should realize that the most important part of a defect is always the steps to reproduce. A defect that cannot be reproduced is only noise, it cannot be solved, because the solution cannot be verified.