I happen to be in Army Officer Candidate School at the moment, and this is how the majority of the selection and training process works. A lot of pressure for people to answer things right now, but most of us don't actually know the answer. Without fail, the most motivated and successful candidates are the ones who say "Sir, Officer Candidate ______, I don't know but I will have an answer to you by [hack time]."

Reminds me of the (probably apocryphal) story about the military officer test that asks "How do you dig up a ditch?" where most candidates answer with detailed instructions about how dig it, when the "correct" answer is something like "I say, 'Private, dig me a ditch!'"

The point being that, at that level, it's more important to know how to deploy your soldiers toward a goal as opposed to the low-level details of every individual task.

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."

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?

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."

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.

> 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.

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?

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.

> 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.

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).

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.

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

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

> It's not just "I don't know" that is important, but also the next part of the thought: "but I can find out."

This isn't about asking someone else to find out how to do it, this is about solving a problem, which may no solution.

So saying, "but I can find out" it is comically ridiculous.

Consider this, how are you going to solve the traveling salesman problem, for 10,000 nodes on your iPhone in 5 seconds?

I don't know, but I can find out.

Try space-filling curves! http://www2.isye.gatech.edu/~jjb/mow/mow.html

Sometimes "that's impossible" or "you can't" is the answer you find out. :)

I think this is so absurdly overrated. It's like forcing a toddler to say thank you. "Now, subordinate/rival, What do we say?? I didn't hear the magic words! We need to find out, mmkay? Can you say you can find out?"

You have a point (valid every time someone details the structured behavior he expects of other human beings), but you need people with initiative and positive thinking who can assume control of a situation outside their comfort zone. I'd go nuts working with someone who responded to issues with just "I don't know".