Improving Your Estimates: Part II

This is Part II of a 3 part series detailing common problems with software estimates and some simple ways to handle them. Part I can be found here.

Unfortunately, most of us software developers are pretty bad at estimation. Is it because we're incompetent? Of course not. It's because coding is creative work, and creative work is unpredictable. Writing software is not like working on an assembly line in a factory. Workers on an assembly line put together a product based on meticulous specifications and instructions. When it comes to software, that's the compiler's job. A team of programmers on a software project is analogous to the team of engineers that designed the product being put together on the assembly line. We might use a familiar set of tools and idioms, and carry over techniques and design elements from project to project (just like an engineering team does) but make no mistake: every project is different, and we are inventing/designing/specifying a new product each time.

Luckily, despite the unpredictable nature of the work, there are a few tricks we can use to make our estimates more accurate and more useful, and to prevent scheduling disasters.

Today, I'm going to talk about two ways that an estimate can be interpreted, and the problems that can arise when you mean one thing and your manager hears another.

Problem: Two Kinds of Estimates

Another factor that can cause confusion between managers and developers is that there are two kinds of estimates. An estimate can be categorized by which of the following two questions it answers:

• How much of your time will it take?
• When will it be done?

The answers to these questions can be wildly different. The answer to the first question is (more or less) under your control, and once you start using empirical estimation, you can be relatively confident in your answer.

The answer to the second question, on the other hand, usually isn't under your control. Most development tasks require co-ordination with other people: users, customers, business analysts, QA staff, DBAs, and/or other programmers. All these people have busy schedules too, so when you're ready to co-ordinate with them, they may not be ready for you. A classic example of this situation is a overworked QA department. You may have some code ready for QA, but they might not get to it for two days, two weeks, or longer! You might only spend two days working on a feature, but that doesn't mean it's ready for production in two days!


When the manager is asking the second question (“when will it be done?”), and you answer the first one (“how much of your time will it take?”), you've got a recipe for trouble.

Solution: Be Explicit

The easiest way to deal with this problem is to be explicit in your communication. (In fact, that's a good way to deal with any kind of communication problem.) Tell your manager exactly what your estimate means (“this task will eat up ___ days of my time”, and what it doesn't mean (“this task will be done in ___ days”).

Now it probably won't be that easy. If your manager wants to know when the code will be ready for prime time (will it be ready in time for the demo to the big prospective customer on Friday?), you'll need to figure out who else will be involved, and go visit them with your manager to put together a picture of the schedule for the task. You may even need to get your manager talking to their manager to align the priorities and schedules of the two work groups.

It may seem like a hassle, but it will allow your manager to walk away with an accurate idea of how long things will take, instead of unintentionally promising that prospective customer a feature that won't be ready in time.

---

Stay tuned for Part III next week.