We all have it, problems that prove difficult to fix and working out a fix through obscure code and bizarre unexpected functionality. Slowly, logically working your way through trying to find patterns, errors, mistakes. This process takes time and the issues are often not easily understood by the client.

How does one answer when asked the question "When will it be done?", especially when the client may not understand the inherent complexities of software development?


You answer the question honestly.

You tell them it's a difficult problem, the solution is not obvious, and you are not sure how long it will take to resolve. Promise to update them on your progress every [time frame], so they know you're working on it, and of course, actually send them the updates.

| improve this answer | |
  • 1
    +1, and I would add to this that you also add that based on your best estimate with what you know, you anticipate completion within [completion time frame], and also add a caveat that the actual time to complete will be affected by [reasons]. Honesty is always best and you're customers more likely to work with you if you deal with them without resorting to weasel-words, half-truths, or outright lies. – S.Robins Feb 19 '12 at 3:00
  • 7
    @S.Robins: the danger of giving such a best estimate is that it tends to be reported upwards without the caveat. – Michael Borgwardt Feb 19 '12 at 10:53
  • 1
    I'd give an estimate for the part of the problem domain that you know about. "I'll know more when I've investigated x and can update you then." – James Snell Nov 24 '13 at 16:09

Developers approach a complex problem by decomposing it into smaller ones and solving them separately.

In an ideal world, solving an issue would be a complex problem A and you would be able, in a given time, to decompose it into a short list of small problems A1 to An, for each evaluating the time is straightforward, given that the time required to solve the initial complex problem would be:

enter image description here

with D being the process of decomposition itself.

In real world, the only problem is that t (D ) would actually be bigger than the time you spend resolving the small problems. In other words, in order to get to this level of decomposition of the problem, you practically need to solve the problem itself.

You can still:

  • Separate the given task (solving the issue) into smaller chunks, each chunk being still a complex problem,

  • Evaluate the expected time for each chunk and the corresponding risk.

    For example, the task 1 requires approx. 5 hours, but the risk to being blocked doing it is high, so give 12 hours as your expectation to the customer.

  • Evaluate the dependencies and how they affect the time.

    For example, the task 19 requires 2 hours, and the risk is so low that you can say it's 2 hours for sure. Not 1. Not 3. But task 19 relies on task 24: the task 24 may affect the task 19 in a way that you would require to completely rewrite the code of the task 19 using a different approach.

  • Give all those details to your customer. Don't give the sum.

The last point is important. If you give the sum, let's say 192 hours, the customer believes that it's a very precise metric, and the time you will spend is from, say, 189 to 195 hours.

If, instead, you give the details,

  • The customer who cares will understand that it's not 192 hours. It's 192 hours if everything goes wrong given the risk determined during the assessment. It's also 238 hours if everything goes even worse. It's also 85 hours if everything is ok.

  • As for the customer who doesn't care, he will not read your answer in all cases. All he want is a number, to be able to blame you later. By giving a very detailed answer he will never read, you know that he can't ask you for the time it will take again: you already answered that. He also can't blame you later, since he didn't read the answer in order to calculate the sum.

| improve this answer | |
  • "In real world, the only problem is that t (D ) would actually be bigger than the time you spend resolving the small problems.": Applying this to agile methodologies (e.g. SCRUM) this would mean that you need more time for grooming that for the actual implementation of user stories. – Giorgio Nov 23 '13 at 8:45
  • It is neither 192 hours, nor is it 238 hours or 85 hours. It is all of these values, each one accompanied by a certain probability. – JensG Nov 24 '13 at 16:54

Whatever you estimate don't forget to include Hofstadter's law: It always takes longer than you expect, even when you take into account Hofstadter’s law.

| improve this answer | |
  • Yep, and that's the main reason why most of the complex approaches are typically waste of time. How do you estimate the unknown? Well, by guessing. Knowing that, it is even more astonishing, that applying some uncertainty analysis to one's estimations seems a very rarely used skill these days. – JensG Nov 24 '13 at 16:50

Typically I use a modified formula from CPM/PERT. It's something like this:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

(I'm not sure how to do all the fancy math formatting; if someone wants to edit this for that, then feel free.)

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

I'd emphasize that it could vary significantly, depending on how the project goes. If you reevaluate your project every few days, you could even supply a weekly update. It goes a long way towards satisfying irritable clients. :)

| improve this answer | |

Explaining vague timelines to non technical users is tough. This is true both in creative phases of a project, and when tracking down a pesky bug. In both cases the traditional "decompose the work to smaller pieces" doesn't work as well.

The original task focuses on the latter case so let's dwell on that. If you can't give a timeline, tell the user what you will try and when you will get back to them. When you reach the halfway point on the self imposed timeline give a short and honest email update. At least an hour before the deadline give your formal response. Now you have credibility. If the problem isn't solved at least you are shining some light. It may seem like a waste of time, but it isn't.


Since you can't account for the unknown roadblocks and unforeseen surprises, it can be challenging to estimate with confidence. Ideas:

  • Try a range - "I am sure it will take at least N days (e.g. 3), but might take as many as 4N."
  • Seek the support of more senior engineers in estimating & defending estimates.
  • Work in shorter iterations (Agile / Scrum style) to produce minimum code that adds business value (gaining confidence & trust), then repeat.
  • Learn negotiation skills from a book like the classic Getting to Yes (http://www.amazon.com/gp/aw/d/0143118757).
| improve this answer | |

For new development, especially Agile development:

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exuper

If you are estimating effort and time on fixing some nearly impossible to reproduce error(s) in a hideously overly complex system with very few to no developers with intimate domain knowledge of the system then the only correct answer is "When it is fixed."

| improve this answer | |

Typically, I would just tell them the truth. I would tell them they I don't know right now, and I might have better insight in a week. I would then hand them a ball park with as many squiggles in front of it as you can fit on the paper to indicate that it is a gut feeling based guess. If they start hard-balling you, just start every sentence with "It's possible ..." Usually anyone I do anything for is happy with the "Check back in a week or so, but now all I can say is about 2 months" or something like that.

| improve this answer | |

The Personal Software Process (PSP) focuses on improving estimates. This is achieved by disciplined logging of tasks. This, in essence somewhat "accelerates" the "experience" part of estimating since you will have actual data about typical tasks. Of course, this profession still requires unique solutions to many problems but in my experience, estimates are better after using PSP.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.