4 ms·

My understanding is that it is harder for engineers to estimate how long a job takes, than to do the job. That is to say, that the complexity of doing a time es

My understanding is that it is harder for engineers to estimate how long a job takes, than to do the job. That is to say, that the complexity of doing a time estimation task is higher than the complexity of task you are estimating. I read this in the book "Making Software: What really works and Why we believe it" [0]. The assumption in the article is that an engineer can produce reliable estimates for complex work, and appropriately guide their managers, and don't think that's true. [0] https://www.amazon.co.uk/Making-Software-Really-Works-Believe/dp/0596808321/ref=sr_1_1?keywords=making+software&qid=1569398896&s=gateway&sr=8-1 https://www.amazon.co.uk/Making-Software-Really-Works-Believ...

hyperpallium 7y ago
I recently estimated a task would take 30 minutes. It took 40 minutes to do that estimate. But, TBF, several important decisions were made during the process of estimating, such as what should be excluded from the task, basic organization, and some research. BTW the task being estimated was doing time estimates for a project (which came out to be 2-3 weeks).
- duxup 7y ago
  Often it seems you take the time to properly evaluate the code and changes .... often it seems you are nearly done.
  - basilgohar 7y ago
    This is often overlooked and undervalued — upfront time spent on understanding the problem and designing before getting down to the actual work ends-up saving a lot of actual time. But most people don't have patience for that and think it is wasted time.
    - duxup 7y ago
      Yeah I've only been coding professionally for a year now and I do SO MUCH MORE reading/researching, planning, annotating, and pseudo coding than I ever did when I started. The outcomes are so much more predictable / better quality.
- cwilkes 7y ago
  Obviously we now need an estimate for how long it will take to make an estimate.
- commandlinefan 7y ago
  > I recently estimated a task would take 30 minutes. My boss at my last job told me that he had observed that if he asked somebody “can you get this done by the end of they day”, he would get an accurate answer (either yes or no). Any further out, there was no correlation between what they said and what they actually delivered.
skohan 7y ago
In that case it seems like it would be better for PM's to take the role of task estimation. Of course this only works if they are also the ones accountable for inaccurate estimates.
jtc331 7y ago
I don’t think the article assumes an engineer can produce reliable estimates for complex work; in fact it claims the opposite: > But the reality is that if you can make a probabalistically accurate estimate, then its likely that the task should have been automated by some other means already. In other words, its easy to estimate a task that essentially amounts to copy and pasting some well known CRUD API end point patterns, but any even remotely creative or novel work is almost guaranteed to be totally unknown.
- commandlinefan 7y ago
  > I don’t think the article assumes an engineer can produce reliable estimates Well, he sort of goes back and forth, but he includes this: > The engineer comes back with this simplified description and says he can get a first version produced, but it will take a month instead of 2 weeks. Which I see some variant of every time I see somebody rail against the unrealistic expectations of software estimation (which, by the way, I’ve been seeing people rail against since the late 80’s to no avail). The implication here is that if the manager had just listened to the developer and accepted his initial estimate of one month, the software would have been done in one month: the developer could estimate with precision, but the manager bumbled along and screwed everything up by trying to negotiate it down. This is a dangerous position to take unless you’re absolutely sure about your one-month estimate: if you say one month, he says two weeks and you look him in the eye like the alpha wolf say, “no, one month, and no sooner”… you had damned well better be able to deliver in exactly one month. The reality is there’s probably no way to tell, _especially_ if other people are involved, so you’re better off shrugging your shoulders and saying, “yeah, sure, two weeks”, doing as much as you can, and preparing your story ahead of time.
snarf21 7y ago
Estimates are hard because you are literally making something that has never been made before. Yes, you have experience with sub parts and similar patterns but not the situation of this timeline, this team, this technical debt, etc. Too often the request is along the lines of "How long does it take to build a house?" not "How long will it take to build the house in these blueprints with these systems on top of a mountain that is also impervious to mudslides?". People can generally estimate the former but the latter is all about the unknown details.

hyperpallium 7y ago

I recently estimated a task would take 30 minutes. It took 40 minutes to do that estimate. But, TBF, several important decisions were made during the process of estimating, such as what should be excluded from the task, basic organization, and some research. BTW the task being estimated was doing time estimates for a project (which came out to be 2-3 weeks).

duxup 7y ago
Often it seems you take the time to properly evaluate the code and changes .... often it seems you are nearly done.
- basilgohar 7y ago
  This is often overlooked and undervalued — upfront time spent on understanding the problem and designing before getting down to the actual work ends-up saving a lot of actual time. But most people don't have patience for that and think it is wasted time.
  - duxup 7y ago
    Yeah I've only been coding professionally for a year now and I do SO MUCH MORE reading/researching, planning, annotating, and pseudo coding than I ever did when I started. The outcomes are so much more predictable / better quality.
cwilkes 7y ago
Obviously we now need an estimate for how long it will take to make an estimate.
commandlinefan 7y ago
> I recently estimated a task would take 30 minutes. My boss at my last job told me that he had observed that if he asked somebody “can you get this done by the end of they day”, he would get an accurate answer (either yes or no). Any further out, there was no correlation between what they said and what they actually delivered.

skohan 7y ago

In that case it seems like it would be better for PM's to take the role of task estimation. Of course this only works if they are also the ones accountable for inaccurate estimates.

jtc331 7y ago

I don’t think the article assumes an engineer can produce reliable estimates for complex work; in fact it claims the opposite: > But the reality is that if you can make a probabalistically accurate estimate, then its likely that the task should have been automated by some other means already. In other words, its easy to estimate a task that essentially amounts to copy and pasting some well known CRUD API end point patterns, but any even remotely creative or novel work is almost guaranteed to be totally unknown.

commandlinefan 7y ago
> I don’t think the article assumes an engineer can produce reliable estimates Well, he sort of goes back and forth, but he includes this: > The engineer comes back with this simplified description and says he can get a first version produced, but it will take a month instead of 2 weeks. Which I see some variant of every time I see somebody rail against the unrealistic expectations of software estimation (which, by the way, I’ve been seeing people rail against since the late 80’s to no avail). The implication here is that if the manager had just listened to the developer and accepted his initial estimate of one month, the software would have been done in one month: the developer could estimate with precision, but the manager bumbled along and screwed everything up by trying to negotiate it down. This is a dangerous position to take unless you’re absolutely sure about your one-month estimate: if you say one month, he says two weeks and you look him in the eye like the alpha wolf say, “no, one month, and no sooner”… you had damned well better be able to deliver in exactly one month. The reality is there’s probably no way to tell, _especially_ if other people are involved, so you’re better off shrugging your shoulders and saying, “yeah, sure, two weeks”, doing as much as you can, and preparing your story ahead of time.

snarf21 7y ago

Estimates are hard because you are literally making something that has never been made before. Yes, you have experience with sub parts and similar patterns but not the situation of this timeline, this team, this technical debt, etc. Too often the request is along the lines of "How long does it take to build a house?" not "How long will it take to build the house in these blueprints with these systems on top of a mountain that is also impervious to mudslides?". People can generally estimate the former but the latter is all about the unknown details.