4 ms·

Because management looks at you funny when you say something simple will take 4 months. Then they lie and say that it couldn't possibly take that long. And the

Because management looks at you funny when you say something simple will take 4 months. Then they lie and say that it couldn't possibly take that long. And the reason they lie is because there's no negative to them tying to you. Their job is to get you to go faster, and they are allowed to lie as part of their job, if it makes you go faster. The reality is that it doesn't make people go faster. It makes people leave faster. It makes people give up. Never give an estimate to management. Estimating is their job, as they control the inputs to production. If you give an estimate, they will pressure you to meet it, no matter how unreasonable it later turns out to be. That also makes people want to leave.

jerf 13y ago
While I agree with many of the other reasons and believe people in general can't estimate very well, I believe that for businesses this is indeed the fundamental reason. Even in a relatively understanding and engineering-centric environment, when I give what is probably still a bad under-estimate, I will get pressured on how we can reduce that number. I can't even imagine what it would be like in an environment that wasn't relatively understanding and engineering-centric. If you don't want to hear the truth, you won't. Humans have known that since long before software engineering existed... or a subset of them, at least.
w0rd-driven 13y ago
Management giving estimates? No thanks. I'd rather them take my input and do their job of understanding trends. When I say something takes a long time and it takes longer, I'm not bullshitting. When I think something takes a long time and doesn't, its generally because shortcuts are rarely understood up front. Will I find the same shortest path next time? If I'm doing the same exact work maybe. I do work in a place where we are a software company but very few people, even some of the devs, understand this culture. I don't say something is complex just for the hell of it. I want to give good estimates but at the end of the day that is all it is, a somewhat educated guess before I've gotten in the weeds. I don't need people that absolutely don't understand this concept to mandate a timeline that is unrealistic. It does absolutely no one any favors. That is why I leave. I don't need to promote unrealistic expectations down the line to customers who think everything is extremely simple. Especially when all we do is create custom software where almost 0% is turn key or off the shelf. Its just insulting to continue that nonsense and the quicker I can facilitate a reality check for all parties, the better and more trust is given to my judgment (and theirs if they actually take the time to learn)
- wpietri 13y ago
  > Management giving estimates? No thanks. This is actually achievable in a sane way. I have done it using the XP planning practices. Basically, you make the suit break everything down into relatively small lumps and place them in priority order. Every week, the team completes a few lumps. Before you do them, engineers grade their relative complexity in arbitrary units. (The smallest substantial thing you do is 1 point; something twice as big is 2 points, and so on.) Every week, you count up the points completed. That's your "velocity". From there, you let managers do all the estimating they want to. If they want the complexity of a unit of work measured, they ask the engineers. If they want to know when X will be done, they look at the team's recent velocity, what's in the queue before X, and do some basic math. The nice part about this is the mental judo involved. Whenever they want to know when something will be done, it's their problem to trade features against time. Working like this, it's not geeks vs suits; the suits channel their schedule pressure into productive work: grooming the backlog.
  - w0rd-driven 13y ago
    I misspoke. What you are describing comes from developer feedback but indirectly in a sense. This, I think, is a nice standard of measurement. Its when people solicit absolutely no feedback either in the form of past projects where hours are measured somewhat or what they just "feel" something should take. I'm all for metrics based estimation because that's how most developers would likely estimate. Its when management seems to pull things out of their ass to get a prospective client I have a problem with. I understand when we need money but I can also trace some of our worst clients to some of the most unrealistic estimates we've ever given. They're almost a 1:1 direct correlation and its like no one sees how much of a drain they can be all around.
    - wpietri 13y ago
      I have been there, and feel your pain. It has taken me a long time to learn to say, "Oh, you told somebody that? Well, then you have a problem, don't you?" Of course, there are some companies that are so pathological that this stuff just won't get better: there's a broken feedback loop between the promises and the consequences. Ugh.
greenyoda 13y ago
"Never give an estimate to management. Estimating is their job, as they control the inputs to production." Unfortunately, it gets even worse if developers have no part in making estimates. If management doesn't know the details of your architecture and code-base (or even the other projects you may be working on, if you go high enough up the management chain), they have no way of coming up with a rational estimate on their own. Where I work, VPs are constantly making "commitments" to customers to have certain features implemented by a certain date, and only notifying developers after the fact. Then they wonder why the development organization is "so bad at meeting deadlines". (Needless to say, I have no ethical requirement to honor commitments that weren't made by me and are frequently impossible to meet anyway.)

jerf 13y ago

While I agree with many of the other reasons and believe people in general can't estimate very well, I believe that for businesses this is indeed the fundamental reason. Even in a relatively understanding and engineering-centric environment, when I give what is probably still a bad under-estimate, I will get pressured on how we can reduce that number. I can't even imagine what it would be like in an environment that wasn't relatively understanding and engineering-centric. If you don't want to hear the truth, you won't. Humans have known that since long before software engineering existed... or a subset of them, at least.

w0rd-driven 13y ago

Management giving estimates? No thanks. I'd rather them take my input and do their job of understanding trends. When I say something takes a long time and it takes longer, I'm not bullshitting. When I think something takes a long time and doesn't, its generally because shortcuts are rarely understood up front. Will I find the same shortest path next time? If I'm doing the same exact work maybe. I do work in a place where we are a software company but very few people, even some of the devs, understand this culture. I don't say something is complex just for the hell of it. I want to give good estimates but at the end of the day that is all it is, a somewhat educated guess before I've gotten in the weeds. I don't need people that absolutely don't understand this concept to mandate a timeline that is unrealistic. It does absolutely no one any favors. That is why I leave. I don't need to promote unrealistic expectations down the line to customers who think everything is extremely simple. Especially when all we do is create custom software where almost 0% is turn key or off the shelf. Its just insulting to continue that nonsense and the quicker I can facilitate a reality check for all parties, the better and more trust is given to my judgment (and theirs if they actually take the time to learn)

wpietri 13y ago
> Management giving estimates? No thanks. This is actually achievable in a sane way. I have done it using the XP planning practices. Basically, you make the suit break everything down into relatively small lumps and place them in priority order. Every week, the team completes a few lumps. Before you do them, engineers grade their relative complexity in arbitrary units. (The smallest substantial thing you do is 1 point; something twice as big is 2 points, and so on.) Every week, you count up the points completed. That's your "velocity". From there, you let managers do all the estimating they want to. If they want the complexity of a unit of work measured, they ask the engineers. If they want to know when X will be done, they look at the team's recent velocity, what's in the queue before X, and do some basic math. The nice part about this is the mental judo involved. Whenever they want to know when something will be done, it's their problem to trade features against time. Working like this, it's not geeks vs suits; the suits channel their schedule pressure into productive work: grooming the backlog.
- w0rd-driven 13y ago
  I misspoke. What you are describing comes from developer feedback but indirectly in a sense. This, I think, is a nice standard of measurement. Its when people solicit absolutely no feedback either in the form of past projects where hours are measured somewhat or what they just "feel" something should take. I'm all for metrics based estimation because that's how most developers would likely estimate. Its when management seems to pull things out of their ass to get a prospective client I have a problem with. I understand when we need money but I can also trace some of our worst clients to some of the most unrealistic estimates we've ever given. They're almost a 1:1 direct correlation and its like no one sees how much of a drain they can be all around.
  - wpietri 13y ago
    I have been there, and feel your pain. It has taken me a long time to learn to say, "Oh, you told somebody that? Well, then you have a problem, don't you?" Of course, there are some companies that are so pathological that this stuff just won't get better: there's a broken feedback loop between the promises and the consequences. Ugh.

greenyoda 13y ago

"Never give an estimate to management. Estimating is their job, as they control the inputs to production." Unfortunately, it gets even worse if developers have no part in making estimates. If management doesn't know the details of your architecture and code-base (or even the other projects you may be working on, if you go high enough up the management chain), they have no way of coming up with a rational estimate on their own. Where I work, VPs are constantly making "commitments" to customers to have certain features implemented by a certain date, and only notifying developers after the fact. Then they wonder why the development organization is "so bad at meeting deadlines". (Needless to say, I have no ethical requirement to honor commitments that weren't made by me and are frequently impossible to meet anyway.)