Yak Shaving

(Last post inspired by Dreaming in code...I think)

There is a problem in building software.  We don't know how to estimate how long it will take to build something.  A 2-week project takes 4.  A one month project takes six.  Why is that?  There are a lot of reasons and I won't attempt to cover them all here.  There is one though that I find happens often and which is probably avoidable if we know to look for it.  The concept is sometimes called yak shaving and other times axe sharpening.  It is Zeno's paradox of Achilles and the Tortoise.

Yak shaving as defined by Eric Raymond is "Any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you're working on."  That is, we're so busy solving the pre-problems that we fail to solve the real problem.  This is often the work of someone playing the role of the second stonecutter.

James Gosling called the same phenomenon axe shaving.  This takes its name from Abraham Lincoln's quote, "Give me six hours to chop down a tree and I will spend the first four sharpening the axe."  The idea is that it makes more sense to do the job with a sharp axe than to try to do it with a dull one.  It is better to spend 1/2 hour writing a perl script to make changes for you than 4 hours doing a manual search and replace.  The obvious downside is that people will focus so much on sharpening that they forget to stop and actually chop down the tree.  Gosling says there is a darker side too.

But for me, the big problem with "axe sharpening" is that it's recursive, in a Xeno's paradox kinda way: You spend the first two thirds of the time allotted to accomplishing a task actually working on the tool. But working on the tool is itself a task that involves tools: to sharpen the axe, you need a sharpening stone. So you spend two-thirds of the sharpening time coming up with a good sharpening stone. But before you can do that you need to spend time finding the right stone. And before you can do that you need to go to the north coast of Baffin Island where you've heard the best stones for sharpening come from. But to get there, you need to build a dog sled....

Xeno's paradox is resolved because while it is an infinite sum, it's an infinite sum of exponentially decaying values. No such luck in this case. The tool building jobs just get bigger, and you pretty quickly can lose sight of what it was you started to do.

Creating a tool to create a tool to create a tool is an infinite recursive sequence and will never end.  It's often worth creating the first tool and sometimes the second but the returns quickly diminish even if the time taken to write the tools does not.  It's important to keep in mind the ultimate goal.  If writing the tools takes longer than doing the work the slow way, it's best not to write the tool.  Of course, if we can't estimate how long it will take, it's hard to know when we've crossed the line.

Sometimes the yak shaving happens differently.  Rather than writing a tool to write a tool, we begin writing a piece of the system but decide that what we've written is awful close to a more general purpose tool.  It would be a shame to throw away what we've written by including it only in this one place so we extract it into a library.  Of course, a library takes longer to write than a single function method.  Each time we do this, the original program takes longer and longer to write.

The moral of the story:  be careful every time you add work to a project.  Each time you work on something that is only tangental to the original goal, consider the cost.  There is probably room in the schedule for a few, but it's easy to add too many.  When you do, you'll look back on your overdue project and wonder where the time went.