January 12, 2009
Disciplined TroubleshootingFocus is often a problem for software developers. Doing one thing at a time, and not letting your mind wander or galavanting off into the deep, dark woods where bad sh*t is pretty much guaranteed to happen doesn't come easily to a lot of programmers.
This is especially true when we hit unforseen problems. The temptation to randomly noodle and tweak in the hope that you'll stumble across a solution to your technical murder mystery is too great.
The consequences are similar to what happens when people "refactor" in a similar manner. What they should do is make a single, well-defined, reversible refactoring to the code and then run all the tests to make sure they haven't broken anything. It's methodical. It's focused. It's low risk.
When troubleshooting, the trick is to put on your deerstalker hat, light your pipe and dig out your magnifying glass and start methodically, scientifically gathering evidence, formulating theories that fit that evidence, and making predictions to test those theories. And do all this one theory at a time. If you think it's a problem with the version of the .NET library your using, swap it for another version and see what happens. If that's not the source of the problem, roll everything back to how it was, and come up with another theory.
Check out Google. Collect all the info you can that might relate to your problem. If that draws a blank, email some folks who might have come across this problem before.
Just, whatever you do, don't sit there and poke and prod randomly, making all sorts of changes, commenting stuff out, moving stuff around, adding and removing references and wotnot.
Posted 9 years, 9 months ago on January 12, 2009