Hammock-Driven Development

Part of what drives us as programmers is a desire to solve problems. We get requirements, and our brains immediately begin formulating solutions, which we analyze and from which we pluck the best one to implement. At least, that’s how it’s supposed to work. Then, there are hard problems: problems which are difficult to understand, problems which don’t immediately suggest their solutions, and problems with no best solution but only tradeoffs.

Here is a great talk by Rich Hickey about how to handle these situations. Some of the key takeaways for me were:

• List the things you know, but also what you don’t know. Brain-dumping, or writing things down, is a good tactic for understanding your situation. Write down everything you know, but just as important, what you don’t know. That can keep you from making unjustified assumptions, and provide a road map to further investigation.
• Find the problems in your solutions. As Hickey puts it, “The chances of there being no tradeoffs in your solution are slim.” When you’ve been working for a long time on a hard problem, it’s easy to get excited by the possibility of a solution. Don’t let your excitement blind you to the possible shortcomings of that solution, otherwise you may just find yourself with two problems.
• Always consider multiple solutions. Comparing multiple solutions against each other is a good way to understand the virtues and limitations of each.
• Get away for a while. Here’s where the talk’s title, “Hammock-Driven Development,” comes from. At any point in the process, but especially once you’ve got an understanding of the problem and an array of possible solutions, step away and let things roll around in your brain for a bit. A surprising amount of thinking happens unconsciously, which is why breakthroughs so often happen in the shower, on a walk, or before bed (at least I find that they do).