“Why won’t devs ever just give me a straight answer to when something will be done? I know that estimation is hard, but they have to have some sense for how long things will take, right?”

I bet some variation of this question is asked at least a hundred times a day in dev shops everywhere. It’s not an unreasonable thing to ask. Businesses have payroll to make. They have to decide whether building something makes sense. And they can only do that when they know how long it’ll take, and by extension, how much it’ll cost to build.

Some managers will bring up the old general contractor analogy and say “If I ask a contractor for a price on replacing my water heater I can get it over the phone. Why is it so hard for devs? Surely they’ve done similar projects and can at least give me a ball park estimate, right?”

I’d suggest tweaking that contractor question a little bit and you’ll arrive at something similar to the dev predicament. Ask them for a water heater that can run on gas or electric, measure exactly two cubic feet in each direction, and be painted an exact shade of green. My guess is if you get an answer at all it won’t be an estimate. You might, in a best case scenario, get a call back a week later saying it’s not possible. And devs are asked to estimate more esoteric requests all the time.

Other reasons estimating becomes impossible are:

  1. There isn’t sufficient detail in the request to estimate. To continue our contractor analogy, imagine this request – “How much does it cost to build a deck?”, “Okay, what kind and how big?”, “Look I don’t know, just a deck. You’ve built decks before, right?”
  2. The request may not be possible. Considering the amount of libraries that the average dev needs to interact with, it’s hard to guarantee that any functionality is present and works without actually doing the implementation.
  3. Estimates assume a reliable amount of uninterrupted work time. Most estimates would require devs to have uninterrupted work time, which in most organizations is never guaranteed. If there is no way to know how much time is available for the work, how can any estimate be reliable?
  4. Estimates are treated like deadlines. Most experienced devs have had the dreadful experience of giving an off the cuff estimate only to be held to that deadline and reprimanded when it’s missed. After experiencing this once or twice most devs will either refuse to estimate something or give an estimate so large as to be essentially meaningless. Certainly this is frustrating for a manager, but what better choices do they have?
  5. The organization doesn’t take deadlines seriously anyways. If deadlines are frequently missed and there is no accountability, why would a dev sign up for a deadline in the first place?
  6. Blocking problems are not addressed. This is an organizational failure that breeds distrust. If a dev is asked why something is taking so long, they might take that question seriously. And if they’re good, they’ll provide an answer. It could be something like “it takes two hours to run the CI tests so every iteration takes a long time to test.” Now it’s the manager’s turn. If serious steps are taken to make that better, the dev is under the gun to deliver (and a good dev will like this situation). If the manager ignores it and returns later with the same question, the dev will assume they are not serious about the work and act accordingly.

Enough about why estimates don’t work. Here are some ways that do work:

  1. Estimating a small addition to an existing system similar to already completed work. This is one of few situations where requesting an accurate estimate is perfectly reasonable.
  2. Treat estimates as estimates. Devs will be less reluctant to estimate if they know they can revise when learning more. When managers use estimates as a measure of ‘this is our best guess based on what we know today’ instead of ‘is everyone working of slacking off?’ it fosters sharing and learning intead of defensiveness.
  3. Estimate in orders of magnitude. If you’re following #2, don’t insist on exact estimates. They’ll be inaccurate anyways. But, a dev should be able to tell you if a task should take hours, days, or weeks. Keep in mind, the larger the project, the less likely an estimate is to be accurate.
  4. Treat research as a task. While not satisfying, it is perfectly reasonable for a dev to say “I’m not sure if that’ll work, but I can test a few things and have a better answer in a few days.” Taking the time early in the project to test or prove out concepts is going to have to happen anyways, and better to do it before committing.

Ultimately, writing software is still extremely unpredictable at best, and owning up to that fact and facing the unknowns is often the best we can do.