Problem solving (mostly programming)

So I'm talking to this other programmer and he asked me how I'd go about solving a problem where something is difficult to reproduce. He asked if I had a particular technique. I had to think about it. I have copious notes on the topic, and I've written a few articles about this, and I have a whole slew of things I'd like to turn into a book at some point. But to be honest, I did not have a general technique I use.

That's odd. I should create one of those.

So after looking over my notes on previous projects, here's my official approach. One more thing: this is not "some good ideas", this is meant to be done as a process. Start at #1 and continue to the end. And away we go...

1. Simplify the context, until the problem goes away. If you're wrong about the context of a problem, you can easily misdiagnose it. But most of the time, when people think of simplifying things, they think of reducing it a little. I'm advocating a larger change. Make your whole project much less complicated. As in, make a copy of your entire project (something you can't do with real world problems), then slice it in half. Does the problem still exist? Make a copy of the new project, then slice that in half. Rinse, repeat. Watch for changes in the behavior of the problem. Once it stops happening, or even changes a little, walk back one copy, and then tear off every unconnected thing you can, and I mean everything, until you've reduced it to the bare minimum. Now you've got something.
2. Change the input data. Whatever you're doing to make the problem happen. Does it happen when you click a button? Change that to a keystroke. Does it require some input text, like a path? Change it to a different path. Add some spaces. And as before, watch for any changes in the behavior of the problem.
3. Accurately name the problem. Or better, describe it in as much detail as possible. This will again force you to weed out the unimportant parts and locate the meat of the actual problem. Once this is complete, you should have a fairly clear understanding of the problem. I think this part does apply to non-programming problems, as well. A well described problem is nearly solved.
4. Document any and all variations between what you expect and what happened, even if it's unrelated. To paraphrase Daryl Zero, the best way to find a bug is to look for any bug. You might find a valuable clue. You might find a different bug. but if you document every single odd result, you're guaranteed to find something important.
5. Document what you think the answer is. This is not for you, now. This is for you, later. We'll revisit this in a bit.
6. Nuke it. Bring in the big guns. Leverage the power of your computer or any tools at your disposal to narrow down the problem as fast as possible. Don't half-ass it. Bring every single tool to the table that you have, and use all of them. Don't try to fix a typo by wading through your source code with a text editor. Don't be gentle. Be as aggressive as possible, and you'll have a working solution that much faster.
7. In a LOT of cases, a screen recording will help. You don't know what you're missing until you can watch it again. So grab a good screen recorder and just let it sit in the background while you work for a bit.
8. (alternative) Replace the problem with a hard coded solution. See if another problem exists. If so, maybe fixing this one isn't as important as you think it might be.
9. Don't be afraid to throw it all away and start over. Sometimes a bug is simply a limitation of your design and could be more easily steamrolled than fixed.
10. Apply fix. Look at your results. If they did not work, go back at 1. It won't take long to figure it out.
11. Revisit step 5. What was the actual solution? What did you miss in your diagnosis? What could you have done differently? Answer those a few we times and you'll start getting a really solid idea of how you can improve your bug stomping skills.

That's my simple 10 step method. I'm going to start applying these to everything I do, for the next month, and I'll report back with my success or failure at it. If you have any suggestions or think I could improve these 10 steps, let me know!

-Chilton Webb