- Posted by liammclennan on August 21, 2011
I have tried to solve many problems in my life, with the solutions created falling roughly into two categories: those that I am proud of and those that I would prefer to forget. Attempting to bias my future towards the former category I spent some time examinging what those successfull solutions had in common, and devised the following heuristic that anecdotally appears to work for me. YMMV. I'm probably stupid. The fact is you may be better off to do exactly the opposite of anything I say.
Heuristic for Successful Problem Solving
Break It Down
Start by decomposing a big hairy problem into many small fuzzy problems. Refine or restart this process until a promising design emerges.
Solve a Little Problem
Pick a small fuzzy problem that provides a logical first (or next) step. Learn as much as possible about the problem domain including everything needed to solve the small fuzzy problem and then a little bit more. This means giving up the implied rule that if you're not typing you're not working. It means reading. And prototyping. And decompiling. I know that I need more knowledge and less typing when I find myself slipping into trial and error.
Record What You Learn
When you're on a role or under pressure it can be difficult but I have found it valuable to make sure that I record what I learn. For a web programmer this is often as simple as recording a significant URL for later reference. Here are some concrete examples:
- Write what you have learnt in setting concrete (that's a little joke)
- Begin each spike with a set of questions that the spike aims to answer. I use a readme file located somewhere obvious (such as /project/spikes/name_of_spike/readme). When the spike is complete append the answer to each question to the readme.
- Record notes in a personal wiki. I have a tiddlywiki in my dropbox. I have been recording notes in the same wiki since July 2005.
Do Not Compromise: Measure Twice, Cut Once
Uncle Bob never tires of reminding us that cutting corners makes us move slower. My anecdotal experience suggests that compromising on the solutions to the small fuzzy problems is a mistake. It makes me slower in the medium and long term. Take the time to get the best solution. Rewrite things. To get it right I often have to do things more than once. Many small things working perfectly are how we build big complicated things that work at all.
Management tend to work by intuition. And refusing to compromise on quality intuitively feels like gold-platting that will hurt budgets and timeframes. But it won't. If the goal is the best solution possible then it will help budgets and timeframes. It may be the only way to hit budgets and timeframes. Your boss may say that you are not being pragmatic because she doesn't realise that doing it properly IS pragmatic. The best solutions are produced when the goal is perfection. The old 'be pragmatic' get it done and out the door attitude leads to mediocraty. This is why I like to work on products, where quality is everything.
If You Are Not Winning Stop
If it's not working, for the love of atheist god, quit, walk away, give up, throw in the towel, and then burn the towel.
It's a little known fact that all of Einstein's greatest breakthroughs occured on the can.
Again, I am writing this down because I know that it is true, yet I find it hard to practive, because it is counter intuitive. It always feel like just one more hack will get me over the line. Once more, slipping into trial and error is a sure sign that things are not right. So stop. Get someone else to take a look at it, leave it until tomorrow or take a walk.