Improving Your Estimates: Part III

This is Part III of a 3 part series detailing common problems with software estimates and some simple ways to handle them. Part I can be found here, and part II 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 a couple of similar problems: getting a new assignment while in the middle of an important task or project, and realizing midway through a task that there are complexities you hadn't anticipated.

Problem: Gotchas and Reassignments

There are a few classes of time sinks that are harder to predict than those mentioned previously in this series. These can throw a real wrench in your estimates even when you do use empirical estimation and are explicit about what you're estimating, because they occur less frequently, but often eat up a bigger chunk of time when they do occur.

First, we have the “gotchas”. These are the unanticipated but necessary sub-tasks, the technical hurdles hiding in the details, and those subtle complexities in the problem domain that don't become obvious until you're knee-deep in conditional logic. As the saying goes, the devil's in the details; unless the task at hand is trivial, it's impossible to predict these things before you really dig into the code.

Next, we have reassignments. One of the most common delays in completing an important task is being reassigned to work on something even more important (or, at least, something that someone thinks is even more important). A reassignment may come from a different manager than your original task, and it may be disguised as a request that you “multi-task”, but don't be fooled. You can't work on something new without affecting the schedule of your original assignment.

There's not much that can be done to actually prevent these sources of delays, so we have to take a more reactive approach.

Solution: Early Warning System

When disaster strikes, a little time to prepare can make all the difference. That's why we have hurricane early warning systems; we can't stop the hurricane from coming, but we can prepare for the worst and ride out the storm in safety.

The same principle applies in software development. A key team member running behind schedule can wreak havoc on Gaant charts and project schedules. To a project manager, that's a real disaster! But, if you keep an eye on the weather, so to speak, you can mitigate the risk and prevent a catastrophe. (Even better, unlike real weather, sometimes by giving an early enough warning, you can avert the storm altogether!)

“Keeping an eye on the weather” means stepping away from your keyboard every few hours to think about how things are going. Just because you're being fantastically productive doesn't mean things are going well. (And if things are going poorly, it doesn't mean you've done something wrong!) Any of these warning signs should prompt you to alert your manager that the schedule is at risk:

• You find yourself thinking “Well, that part took longer than expected, but I'm sure this next bit will be easy. I'm sure it will all balance out in the end.” You should never depend on a lucky break to meet your schedule.
• You need input/feedback/help from another person and haven't had a chance to verify that they have time to spare.
• You've discovered a sub-task that wasn't accounted for in your original estimate.
• You've run into an “interesting” technical problem. These can be especially insidious, since you'll feel the urge to hack away and not come up for air until you've solved the problem.
• The domain turns out to be more complicated than you had anticipated. If the problem domain is complex, it's likely there are additional subtleties you will discover as you continue working on the task. This makes it unlikely you will make up for lost time later.
• It looks like you will finish just in time. This is usually a sign that you will finish late, but won't realize it until you're almost done.
• You are reassigned to some other work, even if you don't think it will take long. It's easy to get absorbed in your new task and forget how fast the clock is ticking on your original assignment. If the new task was handed to you by someone other than the person who gave you the original task, it's especially important to make sure everyone is aware of the switch in priorities.

There's no law stating that you can't revise an estimate after starting a task. The beginning of the task is the point in time when you have the least information on which to base an estimate. It would be silly not to refine that estimate as you gather more information. It's better to deliver a valid estimate a day late than to stick with an invalid estimate until the end.

---

And so ends the series. I hope my advice helps you avoid the scheduling problems that are so common in our industry. Remember, delivering reliable estimates takes more than just arbitrarily padding your first guess. By using the techniques described in this series, you can avoid nasty surprises for both yourself and your manager. Not only does this ease project scheduling woes and make your manager's life easier, it makes your life easier too.

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.

Improving Your Estimates: Part I

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

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 techniques we can use to make our estimates more accurate and more useful, and to prevent scheduling disasters.

Today, I'm going to talk about a very common cause of poor estimates: the difference between ideal days and real days.

Problem: Ideal Days vs. Real Days

Early in my programming career, I often found myself surprised, annoyed, or defensive when I estimated some task or feature as “two to three days of work” and someone showed up at my desk asking about it two days later. Eventually I realized the reason for my reaction. When I said “two to three days of work”, that's not what I actually mean. What I actually meant was “this task will take 16 to 24 hours of my uninterrupted time, based on my understanding of the task right now.” The difference between those two phrases caused me, and my managers, many more headaches than were necessary.

There are a lot of differences between the days we're thinking about when we give estimates, and the days that sneak by us so quickly in the run of a work week. When we're thinking about how long a task will take, we consider the details involved in executing that task, but not all the day-to-day distractions that eat up our time but have nothing (or little) to do with that task:

• Meetings.
• Customer support calls.
• Checking email, answering phone calls, and chatting with folks who drop by your desk.
• Helping the new guy set up his development environment.
• Participating in whiteboard design sessions, design reviews, or code reviews.
• Troubleshooting that strange intermittent network or VM issue.
• Helping a junior developer track down an elusive bug.
• Answering questions or pairing with a developer who needs your expertise about that part of the system you know better than anyone else.
• Did I mention checking email?

These kinds of time sinks are easy enough to account for, and most of us get better at factoring them into our estimates as we gain experience in the field. However, Hofstadter's Law (“It always takes longer than you expect, even when you take into account Hofstadter's Law.”) reminds us that we always have room to improve when it comes to providing more accurate estimates.

Solution: Empirical Estimation

Hofstaedter's Law implies that we are bad at estimation, even when we keep in mind that we are bad at estimation, because we are bad at estimating how bad we are at estimation! Fortunately, there's a trick for getting around this sticky problem: basing our estimates on historical data (a.k.a. empirical estimation).

The first step in the process is gathering that data. When assigned a task, record your initial estimate. Then, keep track of the elapsed time you spend on the task, including all the time sinks mentioned above. After a few weeks, you'll have a pretty good data set. Compare your initial estimates with the elapsed times for various tasks. You will probably be surprised by the difference between the two. Ratios of 1:2 and 1:3 are not uncommon.

You'll be tempted to dismiss the results because they make it look like you're a lot less productive than you really are. After all, those elapsed times include time spent on that “emergency” bug fix, the two-hour architecture meeting, and the morning you had to take an hour off to go to the dentist.

Whatever you do, don't give into this temptation to discount the data. All the factors that caused your estimate to differ from the elapsed time for those tasks are likely to crop up again in future tasks. The value in this exercise is forcing yourself to face the facts. All those things contribute to the difference between estimated delivery dates and real delivery dates. In the future, keep this ratio of on-task time to elapsed time in mind, and estimate accordingly.

If you're nervous that these new estimates will make your manager think you're just padding your estimate so you can slack off, explain your thought process. Let him know the task will take 6 hours of intensive work, but empirical measurement shows you that 6 hours of on-task work usually comes with 6 more hours of meetings, assisting other team members, and the like. It may help to record a sample of the types of time sinks you encounter while recording your historical data.

---

Stay tuned for Part II later this week.