Last week I took my car in for scheduled service, and when I asked how long it might take, the guy said it was specified as one-and-a-half hours of labor. He could do that because there are thousands upon thousands of data points where a competent mechanic has performed that exact service, so there is a very clear idea how long it takes.

But ask a researcher how long it will take to find what they’re looking for, and the answer is usually, “I have no idea. I’ll know after I find it.” The path a researcher follows is usually new and unexplored, so it’s impossible to predict how long the path actually is.

Creating new software is much more like research than auto service, because it involves traveling unknown ground. Despite this, software development managers often act as if new development is predictable.

It often isn’t!

Imagine standing on a very tall hill in middle of a thick forest. The hill you stand on is tall enough to rise above the trees. As you look out over the forest, you see for miles around you. Ahead you see another hill sticking above the trees; that next hill is your goal.

You want to reach that hill.

A question arises; you are asked, “How long will it take to reach yon hill? What will you need along the way?”

If there were no trees blocking your view, it would be easy to answer the question. You have some idea how long it takes to walk a given distance. The time it takes to walk to that next hill is a function of the distance you need to cover.

Because your view is clear, you can see any potential obstacles; you can plan to avoid them if possible or bring along the resources to solve them (boots, ropes, ladders, cleats, whatever). And you can calculate how much extra time solving the problems is likely added to your trip.

It’s just common sense: It’s easy to plan a journey when you can see the territory ahead, even if there are obstacles, even if the path is new.

But what if the trees hide your path? It might be as easy as just walking down your hill and making a bee-line for the next hill. There might even be a beaten path making the journey very easy.

Or there might be rivers or ravines to cross. There might even be dragons! You can estimate the best case, problem-free, straight path. But any unknowns you encounter are most likely to increase the travel time, and you have no idea what those unknowns might be.

After you’ve conquered a few forest paths you begin to get an eye for the lay of the land. You begin to get a feel for the kinds of obstacles you’re most likely to encounter. That makes you better at using rules of experienced thumbs to calculate better travel estimates.

But you still never know when there might be dragons. (That is to say, totally unexpected and extremely difficult challenges.)

I’ve used this “hills in a forest” metaphor to (try to, ha!) explain why estimating the time for any project can be tricky if it involves exploring new territory. And the thing is, software development is likely to explore new territory. Invention is often a project requirement, and experience does make you better at guessing what lies ahead.

It’s not a bad metaphor about life: Invention is often a requirement, and experience makes you better at guessing what lies ahead.

So the next time you need to estimate how long a new software project will take, remember the trees. And beware of dragons!