3 ms·

> Development time estimation, and every methodology that attempts it (I'm looking at you, Scrum), are little more than desperate attempts by managers to feel i

> Development time estimation, and every methodology that attempts it (I'm looking at you, Scrum), are little more than desperate attempts by managers to feel in control and relevant. More charitably, they're an opportunity to introduce system 2 slow thinking on the team. There are certainly novel engineering problems that simply won't yield to estimation, but there are also lots of well-solved problems that will. Managing the latter isn't desperate, its just sound practice toward reproducible results (ideally deployed only where reproducible results create value).

avmich 8y ago
> but there are also lots of well-solved problems that will. Certainly when you're writing a double-linked list a third time you can estimate how long will it take you. The problem is that in real life you never solve sufficiently the same well-solved problem. Feature details, matters of integration with other pieces of the system intervene - and in practice those errors introduced by new circumstances are significant comparing to predicted time. So the practice may be sound, but it doesn't give the desired results, like predictability of required time.
- majormajor 8y ago
  So you integrate with a few systems, you learn where the gotchas tend to be, you call those out as things you'd like to know more about when making your initial estimates, etc. Today's software dev has probably integrated with more systems than they have written linked lists. We just have a habit of forgetting all the little details. If you're looking for a formula that lets you estimate once and then move on to the "real work" now that that tedious BS is out of the way, there isn't one. But you can still do something. There's ground between "I can't estimate that in 30 minutes" and "I can't estimate it at all" and it's up to you and your stakeholders to come to terms on how to balance the risks in your estimates (in broad terms: too inaccurate estimates vs too much time wasted estimating requirements that have since changed). (There's a parallel theme in some other comments: "if it's a well-understood problem why am I not using the existing solution?" Similarly, there's a difference between "well-understood" and "perfectly abstractable and automatable", otherwise almost none of us would be employed these days. :) )
Aaargh20318 8y ago
> there are also lots of well-solved problems that will But if it's a solved problem, why not use the existing solution ?
- nradov 8y ago
  Even if the solution exists you still have to integrate and test it. Those tasks can require a lot of engineering labor, but fortunately they're fairly amenable to estimation.

avmich 8y ago

> but there are also lots of well-solved problems that will. Certainly when you're writing a double-linked list a third time you can estimate how long will it take you. The problem is that in real life you never solve sufficiently the same well-solved problem. Feature details, matters of integration with other pieces of the system intervene - and in practice those errors introduced by new circumstances are significant comparing to predicted time. So the practice may be sound, but it doesn't give the desired results, like predictability of required time.

majormajor 8y ago
So you integrate with a few systems, you learn where the gotchas tend to be, you call those out as things you'd like to know more about when making your initial estimates, etc. Today's software dev has probably integrated with more systems than they have written linked lists. We just have a habit of forgetting all the little details. If you're looking for a formula that lets you estimate once and then move on to the "real work" now that that tedious BS is out of the way, there isn't one. But you can still do something. There's ground between "I can't estimate that in 30 minutes" and "I can't estimate it at all" and it's up to you and your stakeholders to come to terms on how to balance the risks in your estimates (in broad terms: too inaccurate estimates vs too much time wasted estimating requirements that have since changed). (There's a parallel theme in some other comments: "if it's a well-understood problem why am I not using the existing solution?" Similarly, there's a difference between "well-understood" and "perfectly abstractable and automatable", otherwise almost none of us would be employed these days. :) )

Aaargh20318 8y ago

> there are also lots of well-solved problems that will But if it's a solved problem, why not use the existing solution ?

nradov 8y ago
Even if the solution exists you still have to integrate and test it. Those tasks can require a lot of engineering labor, but fortunately they're fairly amenable to estimation.