Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When did estimates turn into deadlines?

domainanalysis.io

Post reply on HN
Print view View original

91–100 of 237 posts

Re: When did estimates turn into deadlines?

#91

Post by j1elo »

This is a fun formula that caught my eye a while ago in HN, it looks flashy and very cool. Of course, just like others do their estimations, this one is just a made up formula and without any formal validity, apart from supposedly personal experience:

https://news.ycombinator.com/item?id=37965582

  My estimate math:
  
  R = t × [1.1^ln(n+p) + 1.3^X]
  
  R - time it really takes.
  
  t - shortest possible time it would take without need to communicate.
  
  n - number of people working and involved during the process, both customers and developing organization.
  
  p - longest communication distance network involved in the project (typically from the lowest level developer to the end user)
  
  X - number of new tools, libraries, techniques, used in the process.
  
  Example. Project involving one developing writing code. Project would take 2 weeks (t=2), but it has 5 people (n=5) involved total, only 1 new tool (X=1) and longest communication distance is 4.
  
  2×(1.1^ln(5+4) + 1.3^1) = 4.5 weeks.

Re: When did estimates turn into deadlines?

#92

Post by makz »

dredmorbius wrote: post #15
nextworddev wrote: post #6

Multiply your original estimate by 3, works most of the time

Heuristics I'd learned was "double the time and bump the unit". So: 2 hours -> 4 days, 1 week -> 2 months, etc. (I'm not sure where this turned up, but it's a long time ago, going on three decades.) The other option is to carefully track tasks, relevant dimensions, estimates, and actual performance, and see if there's any prediction modelling which can be derived from that. Problem is that this a classic instance of…

So 1 year -> 2 decades?

Re: When did estimates turn into deadlines?

#93

Post by milesvp »

jappgar wrote: post #54

A lot of ink has been spilled on this topic. The solution is simple: get better at estimating. Software engineers act as if they're the only ones in the world who are asked to estimate and then held accountable. It's a skill issue.

> It's a skill issue.

Maybe. Sort of. Skill hints at the problem, but it's more of an experience issue. More experienced developers can give pretty reliable estimates for work they've already done. The catch is, how often do you ask an engineer to do something they've already done? The beauty of software, is that you don't solve the same problem over and over, because if you did, you'd automate it.

So where does that leave us? Well, developers who've seen a lot of different problems recognize when a new problem they see rhymes with a problem they've solved before. That can allow for a very good estimate. But even then, engineers tend to think in terms of best case, or maybe even typical case. I saw a study on this a few years ago, and it showed how often engineers tended to cluster around the median time for solutions. But, since really long tasks, with big error bars have a tendency to really skew timelines, the solution averages was much farther from these median times.

Believe it or not, lawyers have this problem too. They are taught in law school to come up with an estimate based on expected effort, then they apply a formula similar to: double the estimate, then increase the time units. So a 5 hour task becomes 10days. A 2 week task becomes 4 months. Mind you, this isn't the amount of billable hours they're predicting, it's the amount of calendar time that a given task will take until it's complete. This ends up taking into account a lot of variables that lawyers have no control over. Things like court scheduling, or communication delay. I suspect it also takes into account blind spots we humans have around time estimates in isolation. Like, 1 task, if you can focus on it can be done in so many hours. But if you have to do 5 similarly sized tasks, it takes more than 5 times as long, simply because it's easy to expend resources like brain power, and the estimate ignores the refractory periods necessary once the task is completed. (BTW this was one of the problems with the very first stop watch study in the rail yard, where the rail workers didn't work at their sustainable pace, but worked at their depletion pace).

Re: When did estimates turn into deadlines?

#94

Post by gopher_space »

jappgar wrote: post #54

A lot of ink has been spilled on this topic. The solution is simple: get better at estimating. Software engineers act as if they're the only ones in the world who are asked to estimate and then held accountable. It's a skill issue.

If you're hiring architects and engineers to design and build your home, you might already have a pretty good idea of the home you want. The people you've hired provide estimates on cost and timing based on solidly known quantities. They've put in a basement like that before. They've worked with your weird materials. Their vendors report on material status daily.

Software development is not surrounded by this sort of infrastructure or codification. My discovery process establishes these lines of communication, and I have no idea when I'll uncover a black box or when one will be imposed upon me.

Re: When did estimates turn into deadlines?

#95

Post by mewpmewp2 »

xedrac wrote: post #90
jimmydddd wrote: post #85

Earlier quoted context omitted.

But you have to remember that the manager is going to be asked for an estimate by his boss. He can't just say some time between "1 day and 10 years." In the real world, you have to be able to give some sort of estimate and help the poor guy do his job.

And thus we get to the root of the problem. As as business executive, why not simply track how long your big projects tend to take, rather than try and dictate how long they should take?

How can you tell what is worth doing if you don't know how long it might take?

Re: When did estimates turn into deadlines?

#96

Post by senkora »

the8472 wrote: post #49
jph wrote: post #44

Estimates are tricky because different manager roles and different personalities bias toward totally different/incompatible concepts of what an estimate actually means. The author's article is conflating realistic and pessimistic estimates: - Realistic e.g. tech managers and people who favors agile/lean/XP/etc. - Optimistic e.g. sales managers and people who want to promote. - Pessimistic e.g. risk managers and peopl…

Sounds like they need curves (probability distributions), not point estimates.

+1. I wrote myself a script that does this with distributions based on my personal time tracking data for doing certain tasks.

More concretely, I sample with replacement N times from the empirical distributions of each step, then sum the steps to get N “samples” from the total distribution.

This is called bootstrapping: https://en.m.wikipedia.org/wiki/Bootstrapping_(statistics)

It isn’t too hard to do, and I can confirm that it works reasonably well.

Re: When did estimates turn into deadlines?

#97

Post by mewpmewp2 »

aoeusnth1 wrote: post #45
redleggedfrog wrote: post #9

I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone…

In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent. The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks. Maybe this is a good strategy for dealing with people who aren’t going to judge you for delivering slowly, or for managers who don’t know what the fuck is going on. For managers who…

I've been considered high performer everywhere I went, only when I was beginning I usually gave very low and naive estimates, experience has taught me otherwise. Of course it will also depend on who and why I'm giving those estimations to.

Usually there are just too many unknowns that higher estimate is justified to avoid having to explain why you didn't make it by certain deadline. The estimates I give are not median or average that I expected the task to complete, they are so that I can be 95% sure it's possible to do it and then some.

Re: When did estimates turn into deadlines?

#98

Post by andai »

redleggedfrog wrote: post #9

I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone…

Reminds me of Hofstadter's Law: It always takes longer than you think, even when you take into account Hofstadter's Law.

We could say, always say it will take longer than you think?

Though by this principle, it seems that "overestimates" are likely to be actually accurate?

Joel Spolsky wrote about his time estimation software which recorded the actual time required for completion, and then calculated for each person a factor by which their estimates were off, and this factor was consistent enough that it could be reliably used as a multiplier to improve estimation accuracy.

> Most estimators get the scale wrong but the relative estimates right. Everything takes longer than expected, because the estimate didn’t account for bug fixing, committee meetings, coffee breaks, and that crazy boss who interrupts all the time. This common estimator has very consistent velocities, but they’re below 1.0. For example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}

https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

Re: When did estimates turn into deadlines?

#99

Post by mewpmewp2 »

bdangubic wrote: post #86
eminent101 wrote: post #50

Earlier quoted context omitted.

So many bold claims in this comment and little to no justification. For what it's worth I've seen pretty much the opposite. I don't know about competent vs. incompetent engineers. But when it comes to experience, I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates.

I think general problem on HN is that you can't say something "bold" without people going "nuts" - especially when it comes to estimating work. In my experience (been hacking since the '90's before it was cool) great developers are great at estimating things. And these are not outliers, all except 1 great developer I've had pleasure of working with over these years has never been "off" on estimates by any statistical…

It really depends on what you are working on. When I did agency type of work, building things you have built before, from scratch, it's easy to estimate. E.g. some sort of e-commerce website from scratch. On the other hand, working in a large corp, with massive legacy systems, unknown domain knowledge and dependency on other teams, it becomes near impossible. What might have been a 2 hour task in agency, might either be completely impossible during our lifetime unless the whole company was built from scratch or take 2 years. You might need 6 other teams to agree to make some sort of change, and you first might have to convince those teams, and then 2 teams will initially agree to it, then pull out in the last moment, or realize they can't do it.

Re: When did estimates turn into deadlines?

#100

Post by zelphirkalt »

mewpmewp2 wrote: post #95
xedrac wrote: post #90

Earlier quoted context omitted.

And thus we get to the root of the problem. As as business executive, why not simply track how long your big projects tend to take, rather than try and dictate how long they should take?

How can you tell what is worth doing if you don't know how long it might take?

You make projections instead of estimates. You split the work that needs to be done into many tasks and project from past experiences.

You cannot rely 100% on any estimates either, and all you are doing by demanding estimates is creating stress and making people less productive. The meta work imposed by that in itself will make a project take more time, as everyone will be padding their estimates.

Post reply on HN