3 ms·

> I'm curious, have you put it into numbers? You can probably even make stuff up (AKA estimate), as long as it has a rational basis. Engineers and developers u

by dozzie 10y ago

> I'm curious, have you put it into numbers? You can probably even make stuff up (AKA estimate), as long as it has a rational basis. Engineers and developers usually have a strong aversion to giving out numbers out of the ass, and you cannot give such an estimate in any other way (barring the cases of the most trivial patches).

taeric 10y ago
I disagree here. Engineers and developers are great at making up numbers. Consider how many times in this thread where people will refer to "9 times out of 10" or other such statements. (Oddly, I have noticed that most of the numbers engineers make up are of the "90% of the time" variety. As if spouting a loose statistic is fine, but a date?! How could we?) I think the problem is that we often think giving a point estimate somehow has to be 100% accurate. Or, worse, we estimate only on the lines of code that will be created and forget that it is all of the lines of code discarded in the process that take most of the time. So, no, refusing to give a date doesn't do service to this. If something is going to take a long time, talk to the reasons it will take time. But FFS, do not focus on some intrinsic quality of the existing code base that is meaningless. It is not a customer problem that there is cruft in the codebase that embarrasses you. It is a customer concern that the last X times a feature was added you spent Y hours dealing with high priority bugs that resulted from compromises. And if you don't know X and Y, than you are worse than making shit up, you are losing credibility.
- flukus 10y ago
  > I think the problem is that we often think giving a point estimate somehow has to be 100% accurate. That's a learned behavior from all the times that estimates become deadlines.
  - taeric 10y ago
    Then the learned behavior should be to remember the reason the estimates were wrong last time, and to include those this time. And no, I do not think it is that easy. The point is that refusing to speak simply robs the process of valuable input.

by dozzie 10y ago

taeric 10y ago

I disagree here. Engineers and developers are great at making up numbers. Consider how many times in this thread where people will refer to "9 times out of 10" or other such statements. (Oddly, I have noticed that most of the numbers engineers make up are of the "90% of the time" variety. As if spouting a loose statistic is fine, but a date?! How could we?) I think the problem is that we often think giving a point estimate somehow has to be 100% accurate. Or, worse, we estimate only on the lines of code that will be created and forget that it is all of the lines of code discarded in the process that take most of the time. So, no, refusing to give a date doesn't do service to this. If something is going to take a long time, talk to the reasons it will take time. But FFS, do not focus on some intrinsic quality of the existing code base that is meaningless. It is not a customer problem that there is cruft in the codebase that embarrasses you. It is a customer concern that the last X times a feature was added you spent Y hours dealing with high priority bugs that resulted from compromises. And if you don't know X and Y, than you are worse than making shit up, you are losing credibility.

flukus 10y ago
> I think the problem is that we often think giving a point estimate somehow has to be 100% accurate. That's a learned behavior from all the times that estimates become deadlines.
- taeric 10y ago
  Then the learned behavior should be to remember the reason the estimates were wrong last time, and to include those this time. And no, I do not think it is that easy. The point is that refusing to speak simply robs the process of valuable input.