4 ms·

> Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know wha

> Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have at the end of the process." If that's the actual answer, then anything else is just obfuscating the truth. Why should we encourage lying to try to cover for the fundamental lack of knowledge? If you don't know, trying to make up numbers never makes things better.

pekk 13y ago
Making up numbers doesn't make things better for you or for delivery of the project. But it makes you liable to the boss, so they can make your head roll if they need to. A surprising number of people in business think this way: not that they need to make sure of something, but just that they need someone to tell them everything will be OK, and then put the blame on if anyone is unhappy. That someone will naturally be whoever is at the bottom of the totem pole.
- robotys 13y ago
  This remind me that business is pure gamble, and business people is bad gambler. They want to play but do not want to lose and if they lose they want to blame somebody. Managing ego and heart is harder than managing a project i think.
  - gizzlon 13y ago
    The Second Law of Consulting: No matter how it looks at first, it's always a people problem. Gerald Weinberg http://en.wikiquote.org/wiki/Gerald_Weinberg#The_secrets_of_consulting.2C_1985 http://en.wikiquote.org/wiki/Gerald_Weinberg#The_secrets_of_... http://www.codinghorror.com/blog/2008/01/no-matter-what-they-tell-you-its-a-people-problem.html http://www.codinghorror.com/blog/2008/01/no-matter-what-they...
    - gizzlon 13y ago
      haha, I love this guy.. Asking for efficiency and adaptability in the same program is like asking for a beautiful and modest wife. Although beauty and modesty have been known to occur in the same woman, we'll probably have to settle for one or the other. At least that's better than neither.
      - _glass 13y ago
        No haha, this is just plain sexist and wrong. One of this wonky generalizations and why we don't have real software engineering yet.
derefr 13y ago
"Make up numbers" glosses over a bunch of actually-useful techniques, though. You might not have any data to begin with, but you can certainly get some. For example, since a time estimate can trivially be converted into probability estimate for something happening on time, all of this is relevant: http://lesswrong.com/lw/3m6/techniques_for_probability_estimates/ http://lesswrong.com/lw/3m6/techniques_for_probability_estim.... The best technique from that set, I usually find, is betting (with actual money) on results: setting up a intra-company prediction market for when your software will ship can tell you more than you ever wanted to know about how much time it'll truly take.
Angostura 13y ago
> If that's the actual answer, then anything else is just obfuscating the truth. There are three possible reasons for an answer of 'I don't kmow' 1. Something is unknowable 2. The person being question has insufficient expertise to discover the answer 3. The person being questioned hasn't really thought about it. You appear to be assuming that 1 is always the reason.
- jaggederest 13y ago
  There's a lot more than those three possibilities. I don't really believe that anything is unknowable, aside from semantic arguments about Godel's incompleteness and things like that. What I'm saying is, that at the moment someone asks you "How long will X take to bring through the software development process", "I don't know" has to be a possible answer or your whole method is corrupt.

pekk 13y ago

Making up numbers doesn't make things better for you or for delivery of the project. But it makes you liable to the boss, so they can make your head roll if they need to. A surprising number of people in business think this way: not that they need to make sure of something, but just that they need someone to tell them everything will be OK, and then put the blame on if anyone is unhappy. That someone will naturally be whoever is at the bottom of the totem pole.

robotys 13y ago
This remind me that business is pure gamble, and business people is bad gambler. They want to play but do not want to lose and if they lose they want to blame somebody. Managing ego and heart is harder than managing a project i think.
- gizzlon 13y ago
  The Second Law of Consulting: No matter how it looks at first, it's always a people problem. Gerald Weinberg http://en.wikiquote.org/wiki/Gerald_Weinberg#The_secrets_of_consulting.2C_1985 http://en.wikiquote.org/wiki/Gerald_Weinberg#The_secrets_of_... http://www.codinghorror.com/blog/2008/01/no-matter-what-they-tell-you-its-a-people-problem.html http://www.codinghorror.com/blog/2008/01/no-matter-what-they...
  - gizzlon 13y ago
    haha, I love this guy.. Asking for efficiency and adaptability in the same program is like asking for a beautiful and modest wife. Although beauty and modesty have been known to occur in the same woman, we'll probably have to settle for one or the other. At least that's better than neither.
    - _glass 13y ago
      No haha, this is just plain sexist and wrong. One of this wonky generalizations and why we don't have real software engineering yet.

derefr 13y ago

"Make up numbers" glosses over a bunch of actually-useful techniques, though. You might not have any data to begin with, but you can certainly get some. For example, since a time estimate can trivially be converted into probability estimate for something happening on time, all of this is relevant: http://lesswrong.com/lw/3m6/techniques_for_probability_estimates/ http://lesswrong.com/lw/3m6/techniques_for_probability_estim.... The best technique from that set, I usually find, is betting (with actual money) on results: setting up a intra-company prediction market for when your software will ship can tell you more than you ever wanted to know about how much time it'll truly take.

Angostura 13y ago

> If that's the actual answer, then anything else is just obfuscating the truth. There are three possible reasons for an answer of 'I don't kmow' 1. Something is unknowable 2. The person being question has insufficient expertise to discover the answer 3. The person being questioned hasn't really thought about it. You appear to be assuming that 1 is always the reason.

jaggederest 13y ago
There's a lot more than those three possibilities. I don't really believe that anything is unknowable, aside from semantic arguments about Godel's incompleteness and things like that. What I'm saying is, that at the moment someone asks you "How long will X take to bring through the software development process", "I don't know" has to be a possible answer or your whole method is corrupt.