Software development is a lot like meeting a friend for dinner. I’m serious! Every now and then I find myself sitting at a restaurant bar at 6:58 waiting for my friend to show up for our 7 o’clock reservation. All of a sudden I get a text: “Running 5 minutes late. See you soon.” Well, that’s fine. I tell the host that I’m present for the reservation but my friend is running late. He says it’s fine and ask if I want to sit down at a table while I wait for them, and I say no, because that sounds awkward.
At 7:07 my friend texts me: “I’m almost there.”
At 7:12 I tell the host that I’m still waiting for my friend, and is that alright, and he assures me that it’s fine, but I’m a little worried that it’s not.
At 7:15 my friend shows up and apologizes profusely. The host seems relieved that we got our act together before he had to give away our table.
Why did this happen? How can it be prevented? Before we get into that, let’s reiterate our symptoms:
- The first time estimate was wrong.
- I wasn’t informed that my friend was running late until right before the appointed time.
- The second time estimate was wrong.
- I didn’t know when my friend would really be there until they actually appeared.
You can observe these exact four symptoms on many delayed software projects. The primary difference is that it happens over the course of weeks, not minutes. And of course, the stakes are higher: software development delays are much more problematic.
I propose that the skills that could have helped my friend show up to dinner on time could also help software teams deliver software on time. It’s not the same thing, of course: there is a lot more complexity in software development than simple time estimation. However, developing your time estimation skills is extremely useful.
I live in the same city as my tardy friend, so I can make a good guess at what they did wrong. Here is a possible timeline for their trip:
- Walk to the subway
- Wait for the subway
- Take the subway
- Walk to the restaurant
Here is what their original estimate might have looked like:
- Walk to the subway (less than 5 minutes, round down to 0)
- Wait for the subway (0-10 minutes, assume 5)
- Take the subway (15 minutes)
- Walk to the restaurant (not considered)
Total: 20 minutes
There are two primary problems with this estimate:
- Small tasks were assumed to be negligible or were not considered.
- Tasks that could take a range of durations were averaged instead of being given enough time for any scenario.
Here is a better estimate:
- Walk to the subway (less than 5 minutes, leave time for 5)
- Wait for the subway (0-10 minutes, leave time for 10)
- Take the subway (15 minutes)
- Walk to the restaurant (less than 5 minutes, leave time for 5)
Total: 35 minutes
My friend’s original estimate was optimistic by 15 minutes. Let’s assume they departed at 6:40. They didn’t make sure they were on-schedule during those 20 minutes, but once they realized it was almost 7, they texted me to tell me they’d be late. However, they didn’t revisit the schedule and make a new estimate: they just picked a small amount of time that wouldn’t upset me.
There are a variety of skills that would have helped my friend in this situation:
- Ability to think through all the tasks involved in a process and make sure they’re all included in the estimate.
- Willingness to leave enough time for tasks that can take a range of different durations.
- Ability to recognize deviations from the latest estimate as early as possible.
- Ability to revise the schedule dynamically in light of new information.
- Willingness to share estimate revisions promptly and transparently.
Work on these skills if you want to be good at what you do. It’s useful to revisit your initial plan at the end of a project to recognize problems you had and learn to avoid them in the future.
Time estimation skills are useful for getting to dinner on time, they’re useful for software development, and, hell, they’re useful for pretty much anything. Practice by getting to dinner on time; in other situations the stakes are much higher.