Diamond Cutting

This little bit of wisdom was ripped from Ned Batchelder's blog (http://www.nedbatchelder.com/blog/200404.html)

Diamond Cutting

I was talking with a fellow software engineer the other day about the process of designing software, and we got around to the diamond cutter analogy.

A diamond cutter (so I am told) takes a raw lump of diamond and has to cut it in just the right way to make a properly cut finished diamond. With large diamonds, the first cut is crucial, and can be an all-or-nothing proposition. Strike the diamond properly, and it is worth millions. Strike it wrong, and you have a pile of cheap industrial chips. There are stories of diamond cutters staring at rough diamonds for weeks trying to discern the right place and angle to strike.

Sometimes software design is like that. How should a pile of functionality be divided into modules and classes? What's the right separation of concerns? Which patterns will provide the best leverage over the forces of chaos? As with diamond cutting, the best answer may not be immediately obvious. Make the first cut incorrectly, and you could be struggling hard against a ragged grain for the whole rest of the project. Strike it right, and you could have a smooth, strong, easily-implemented interface.

When designing software, sometimes we have to mull a problem over, examine it from every angle. Simply starting out and figuring you'll hack your way through it may leave you with an unmanageable mess. Next time you're in this position, try letting it sit. The proper grain may become apparent to you over time. You may end up with a beautiful diamond instead.

---

This is actually a surprisingly apt analogy. Why? Consider what would be different in the world of diamond cutting if you could make that cut, and if it didn't work out, try again immediately with a different cut?

• There are a number of attractive facets to this analogy that we should reflect on. :-)

The economics of the two endeavors differ greatly. As described above, DiamondCutting loads most of the cost at the beginning -- BigDesignUpFront with a vengeance, as it were. For programming, the cost of throwing one away is low enough that practices such as SpikeSolution and IterativeDevelopment are feasible. Sometimes it's better to try (recognizing the possibility of failure) than to succumb to AnalysisParalysis. Isn't that one of ExtremeProgramming's goals: reducing the cost of change to the point where refactoring and redesign become habit, not painful exception?