Estimation wizardry

Quick! How much time will it take to fly around the world? How much cloud storage would it take to store a million books? How many days do you need to finish the project?

While not a technical blog-post, estimation is something all developers come across in their professional careers. I’ve known managers to take the estimated time of a developer and double (or even triple) it.. This means we're not really good at it, but it is a skill that can be learned. While not an exact science, estimations can be correct to some extend. They are important, as estimations are not only the base for the budget allocations, but also for the flow of the entire project.

Fast is fine, but accuracy is everything

Or is it ? How accurate is accurate enough? It is very important to take into account the context in which the estimation will take effect. Is a shot in the dark good enough, or does the context require a more accurate estimation?

If your grandmother asks when you will arrive, she’s probably wondering whether to make you lunch or dinner. On the other hand, a diver trapped underwater and running out of air is probably interested in an answer down to the second.
- The Pragmatic Programmer, Andrew Hunt & David Thomas

Interesting about estimating is that the units you use make a difference in the interpretation of the result. When you say that something will take about 120 working days people will assume that your estimation will be more accurate than when you say something will take 6 months. Then they will know to look between 5 and 7 months from now, as opposed to somewhere between 117 and 123 days.

Choose the unit of your answer to reflect the accuracy you intend to bring over.

Understand the question

Of course, this is a golden rule. You will never be able to perform an accurate estimation if you don’t understand the question. You need to be able to get a grasp of the domain and if there are any environmental aspects you need to take into effect.
The only way to achieve a complete and full understanding of the problem you need to ask questions and maybe do a little research or analysis. Try to map out the problem in your head and locate the dark spots. Often it’s these spots that cause a project to go over-budget.

If there is a similar solution available that encapsulates a part of the question, be sure to take that into account as well. The estimations you take from existing material will always be the most accurate.

To break a mental model is harder than splitting the atom

It’s important to build a mental representation of the problem. If the question involves response time, you model might involve a server and network traffic. For a project, it might involve the business processes in your company, the project team and a rough ground-plan of the architectural layers and patterns.

How complex is your model?

Often the process of building the mental model leads to underlying patterns, processes or complexities that weren’t apparent on the surface.
It is, however, not a good idea to construct a model that is to complex. A higher level of complexity does not automatically mean a huge impact on accuracy-levels. Just create a top-level overview, get a rough idea and base your estimations on that.

Break the model in components and assign values

Once you have your mental model you can split it up into components. You’ll need to discover how these components interact with each-other and what their values are for the project as a whole. You’ll find that each component will typically have parameters that affect how they contribute to the overall model.
Once you have a look on these parameters, you can go through them and assign each one a value. Find out which parameters have the most impact on the result, and concentrate on getting them as accurate as possible.
For the response-load example, you hardware can be a component, and the amount of RAM memory can be a parameter.

Provide your answers based on your calculations

Only in the simplest of cases an estimate will have a single answer. As the systems gets more complex, you’ll want to investigate your answers further. Run multiple calculations, varying the values of the critical parameters, until you work out which ones really drive your model.
Provide your estimation in terms of the calculated parameters. ‘The response time is roughly three quarters of a second if the application is stored on a dedicated web-server, and one second if it is stored in a clustered environment.’ (Notice how ‘three quarters of a second’ conveys a different feeling of accuracy than 750 ms.)

Project durations

These rules for estimating can break down in the face of the complexities and variations of a sizable development project. There is simply no way to obtain enough information and parameters to get a global view of the scope. Building the mental model and defining the parameters and their values are made impossible. Often, the only way to determine the duration of a project is by gaining experience on that same project, or a very similar project, with the same team-members. When you practice incremental development, you can repeat the following steps:

• Analyze requirements.
• Analyze risk and setup test scenario's.
• Design, implement, integrate.
• Validate test scenario's.
• User Acceptance Testing.

Initially, you may have only a vague idea of how many iterations will be required, or how long they may be. Some methodologies require you to nail this down as part of the initial plan, but for all complex projects this is a mistake.
Unless you are doing an application similar to a previous one, have hand-on experience in the domain and technical aspects and know the individual skills of the team-members you’d just be guessing.

After the experiences gained in the first increment, you can refine your initial guess. The refinement gets better and better each time, and confidence in the schedule grows along with it.

Off course, this will not be popular with management, who typically want a single number before the project starts. It'll be your job to make them understand that the team, their productivity, and the environment will be the main parameters defining the schedule. By formalizing this and refining the schedule as part of each iteration, you’ll be giving them the most accurate estimates you can.

Keep track of your progress

It’s vital to keep track of your estimates. When (not if) an estimation turns out wrong, examine why it turned out wrong. Maybe you didn’t understood the scope well enough, maybe some parameters didn’t match the reality or maybe the base model was wrong.
Whatever the reason, take the time to investigate your errors, so you may learn from them in the future.

What you say when asking for an estimate

You say ‘I’ll get back to you’. You almost always get better results if you slow the process down.

Final thoughts

Estimating is a very important skill and should be taught more in junior development roles. And not only do we need to teach the skill of estimation, but also clearly define the concept ‘definition of done’. This concept often has a different meaning with each stakeholder working on a project.
It should be clear however, that estimating is a key aspect in any-ones professional career, and it should be treated as such.

This blog-post was greatly inspired by chapters in the book 'The Pragmatic Programmer' by Andrew Hunt and David Thomas. If you haven't already, be sure to read it, as it targets almost all important aspects in a programmer's professional career.