We've all heard someone say something like:

Estimation is impossible.

What's the point in estimating?

Every estimate is just a SWAG.

One of my early experiences as a professional software developer was when a project manager brought me aside and told me that the way to make estimates was by the following process:

1. Write down how long you think it will take. Example: Two weeks.
2. Double it. Example: Four weeks.
3. Increase the unit. Example: Four months.

What is estimation?

If all of these things are true, what even is estimation? I think this unanswered question is core to the myth of "estimation is impossible." Whenever I am in a conversation about estimation, I always come away with the strong sense that everyone is talking about different things. One person says estimation is possible because their company delivers to deadlines all the time, proving so. Another person is adamant that developers can't make estimates because too much is outside of their control or even outside of their knowledge. A third will say that software is an amorphous intangible abstraction so you can't estimate it.

None of these people defined estimation. Is it a deadline (a date) when something is delivered? Does estimation inherently involve knowing exactly what that something is? Is estimation inclusive of how many people, how much money, and for how long a company will work on one "thing?"

Estimation techniques

Besides the lack of clarity, there's another problem I find in these conversations. They only involve the following estimation technique:

Sit down and stare at the wall for awhile, then write down how long you think it will take to deliver the functionality in question.

At best, people discuss "planning poker" or having a conversation among the entire team about the delivery of a feature. Besides just arbitrarily throwing out numbers, this is the only game in town.

Learning to estimate

Did you know that the average developer tenure of tech companies is less than 2 years?

I bet if you think of all the people you've ever worked with, the colleague who made the most accurate estimates was either someone who had worked at your company for a long time or someone who worked in the same general industry (maybe e-commerce or SaaS).

This suggests that you can learn to estimate.

It also suggests why no one knows how to estimate.

So how do you?

Steve McConnell, the author of Code Complete, also wrote an oft-ignored book called Software Estimation: Demystifying the Black Art. It tells you exactly how to make good estimates. It defines what estimation is. It gives you more techniques than throwing numbers out. And it boils down to this: every organization can learn to estimate, if they actually kept data on their projects.

McConnell writes the following:

The most important reason to use historical data from your own organization is that it improves estimation accuracy. The use of historical data, or “documented facts,” is negatively correlated with cost and schedule overruns—that is, projects that have been estimated using historical data tend not to have overruns (Lederer and Prasad 1992).

My bet is that no one reading this article has ever worked in an organization that has historical project data from their own organization at hand when they make estimates. I make this bet confidently based on my own experience at six large companies as well as the numerous conversations I've had with software professionals from dozens of other companies including Amazon, Microsoft, and Google.

It sounds shocking that companies have ignored this simple practice, but they have.

Ending on a low note

If you would like to make better estimates, I highly recommend reading McConnell's book, because it will help. Using even the simplest tools that McConnell covers like work-breakdown structures will improve your estimates.

On the other hand, I have bad news. Since you're not likely to work in an organization that collects project data and makes it available to everyone, accurate estimation is effectively impossible, even if it is emphatically not impossible.

I wish you the best of luck.