[chris_mahan]

How can one know how long it will take to get an answer? That's just a lie of bravado, a pressure-driven estimate. It's horrible in a business environment. What happens is the person will give the first answer that makes sense, which, while the answer may be correct, discourages deep analysis of the problem.

I never give estimates, to the great fury of my boss, but I told him I don't want to lie.

Lying is unethical, and accepting a lie, or not calling out a liar, is encouraging unethical behavior.

If someone tells me: "I'll have an answer, or: be done with the work, by a certain date/time, I shake my head, then reply: "Don't make promises. Just let me know when it's done."

[flebron]

So how do you handle any sort of software development planning? Do you just tell the client "It'll be done eventually. I'll let you know when.", or would you accept that reply from your employees?

[chris_mahan]

That's why agile is used: We'll show you what we have at an agreed upon time (1 week, 2 weeks, 6 weeks, whatever) and you can say "that's fine keep going" or "hmmm, we should change direction."

[joncrocks]

But even with agile, you have to have some kind of idea how long an overall project might take, otherwise how do you even decide if a project is worth starting?

Estimating is hard, but it's an estimate. Problems usually arise when one gives an estimate of 'X days' and what the manager hears is 'It will take X days, and no longer.'

An estimate will increase in accuracy the more you know, so if you don't feel comfortable giving an estimate, ask the question: "What information do I need to know to give me comfort for an estimate of Y% accuracy" and ask more questions.

[dragonwriter]

> But even with agile, you have to have some kind of idea how long an overall project might take, otherwise how do you even decide if a project is worth starting?

If each iteration is producing sufficient independent business value (e.g., not dependent on subsequent iterations), then you don't have to estimate the size of the "overall project" to determine if it is worth starting. That's actually a key part of the risk mitigation provided by agile/lean methods.

[rwallace]

I try to avoid giving time estimates where possible as well. In practice sometimes you have to, though, and if you have said "I'll have the answer by tomorrow" and tomorrow comes and this turns out not to be the case, you say something along the lines of: This turns out to be a trickier problem than met the eye; here's what I've found out so far; do you want me to keep looking for a solution?

[chris_mahan]

I work at a large bank (trillions in deposits). When I am asked to give an estimate, I say: "I haven't done the estimate yet."

When they say "How long will it take to do the estimate?" I reply: "I have no idea until I get into the details of the problem."

When management asks for an estimate, with rare exceptions, they actually mean: "We are putting pressure on you to get this done by a certain date, but we don't want to tell you what that date is, and we're betting that if you give us a low estimate now, you'll pressure yourself to meet your own deadline, and we won't have to manage the project."

The problem with that type of reasoning is that in the end, the workers are stressed, and the solution is suboptimal.

[TeMPOraL]

> It's horrible in a business environment.

That may be so, but the military environment is different. Officers need to be able to make good-enough decisions on the spot, without the benefit of careful consideration, because there might be a literal dead line, after which people die. Sometimes being in motion is more important than the actual direction.

[chris_mahan]

If you need to make good-enough decisions on the spot, you need to have people be willing to take responsibility for being wrong, and they need to have decent information available (the decision-maker needs the information, not some other person somewhere else--in companies, information is hoarded horribly).

[sitkack]

There is an important distinction between making an estimate on the spot based on reasonable expectations of the problem ,I am 90% confident I can have switch panel wired in 6 hrs. Verses, I have no clue and need to spend 3 hrs just analyzing the problem before estimating the difficulty.

I have been thinking about this a lot over the past months, most teams and projects fail because people get in over their head by

  * Not analyzing the problem deeply enough (hrs not weeks)
  * Estimating too early, they don't want to look weak
  * Not revising estimates once they are in it (heroic save)
  * Not asking for help or re-analysis from outside minds

On projects that went well, we put concerted effort into mitigating the above failure modes. Being wrong or not knowing is OK, being wrong or not knowing AND NOT fixing it is a huge problem. These issues don't come out of nowhere, there are precursors and warnings far in advance of emergency situations.

As a poster above mentioned, accepting a bullshit answer is being complicit in a lie. We need to push back in a polite way when we are being bullshitted. By accepting poor estimates (in all the dimensions of poor) we enable failure.

[sitkack]

How to Spot A Liar http://www.youtube.com/watch?v=P_6vDLq64gE

http://en.wikipedia.org/wiki/On_Bullshit