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

How I estimate work

seangoedecke.com

Post reply on HN
Print view View original

321–326 of 326 posts

Re: How I estimate work

#321

Post by hyperman1 »

boltzmann-brain wrote: post #193
hyperman1 wrote: post #190

Something I learned on this site: We're bad at estimating the average duration, but reasonable for the mean duration. If you get 10 tasks of seemingly equal duration, 9 will go well and 1 will hit a reef of unexpected troubles and take forever. So the practice of doubling is not that stupid. It leaves time in the first 9 to deal with the unexpected disaster.

except "work expands so as to fill the time available for its completion", and therefore, after each of the 9 tasks is completed, there is no time left for the 10th task. so this only works if the disaster happens very early, or if you do almost all of the tasks in parallel. neither is the expected case.

I tend to have many tasks in parallel, as there are always multiple blocked on input from someone else. E.g.

* 2-3 big programming tasks as focus for this week: I push one forward until I hit a wall, then task switch.

* A backlog of about 5 dumb non-urgent tasks for when the brain is not braining or in meeting filled days.

* 4-5 tasks where I keep asking people questions until the problem is understood. These tend to wake up when receiving information, take priority with 10-30 minutes of writing mails and looking up interesting cases, followed by a few days of waiting for an answer.

Re: How I estimate work

#322

Post by carefulfungi »

genghisjahn wrote: post #313
carefulfungi wrote: post #35

Earlier quoted context omitted.

Sales gets fired (or not paid) for missing their estimates (quotas, forecasts) and often have little empathy for engineering being unable to estimate accurately.

Are you in sales or have you ever worked in sales?

I've been a CTO (with a lot of pre-sales engineering responsibilities) and a VPE responsible for engineering - sales relationships; I've participated in hundreds of prospecting and customer calls and many years of sales planning/strategy/deal review meetings. I can tell you from first hand experience that sales (and marketing, to a large extent) are both strictly measured and held accountable to forecasts. Forecasting a buyer's behavior, or a lead gen pipeline, or deal timing is not easier than forecasting the construction of a new feature.

Re: How I estimate work

#323

Post by napaparts »

arter45 wrote: post #287
napaparts wrote: post #264

Earlier quoted context omitted.

It really depends. Anyone doing meaningful work will have hard time giving estimates. But churning up the next CRUD application with now special requirements can have no unknown variables. The question of course remains, why would anyone want to waste their time reinventing a spreadsheet.

>why would anyone want to waste their time reinventing a spreadsheet I hope this is tongue in cheek, right? If not, here are some reasons: 1) spreadsheets embed "functions" via macros and macros are often flagged as malicious. Just combining native functions can get pretty complex. 2) in a spreadsheet, everybody sees the input, which is not always ideal 3) data types are controlled by users for the entire column or s…

You are correct, comparing making the next CRUD application to reinventing the spreadsheet was supposed to be a slightly humorous way to describe the repetitive and not too challenging part of writing business applications.

There also are people who use software to guide space rockets, cars, optimise calculation algorithms and more.

My guess is people with background mostly in CRUD don't get how everybody else messes up estimating so badly and people in the innovative task group find it hard to believe sane people would waste their time giving any estimates other than for technically irrelevant business reasons.

Re: How I estimate work

#325

Post by jll29 »

My empirical findings (30 year time frame, dozens of projects, a few larger, some small many small-to-medium, median perhaps 18 calendar months with around four people on the core team):

1. Good estimates are possible.

- use intervals, not single numbers; intevals are asymmetric (worst case is far out compared to best and expected cases);

- calculate using PERT estimates;

- estimate by combining top-down and bottom-up estimates; when both agree, trust the estimate; otherwise, refine/revise the plan;

- let the assignee estimate their own work, but the manager correct it (because of (2));

2. Better engineers tend to underestimate their own time more than average performers.

If management tells you how long you got, look surprised and ask them how they can know that; then tell them you will now working on calculating how long it will really take. If their "gut instinct" and your professional estimate diverge, show them your plan, talk them through it, and ask them which part you should leave out (if you keep the time fixed, perhaps you can shrink the scope).

Re: How I estimate work

#326

Post by xelah »

paulddraper wrote: post #47

You wouldn’t put up with this drama from any other professional, I don’t know why I’d take it from a SWE. Timelines can be estimated approximately. I’ve never had a construction project finish exactly on time, but that doesn’t mean estimates are unwise.

I think we should not compare apples to oranges here.

A construction project is not an IT project.

In a construction project, many things can be easily estimated. I know how much concrete, steel, and other materials I need. I can estimate how long it will take to get them delivered. I can estimate how long it will take to build this one specific part. Sure, there are unknowns, but they are usually (not always) due to human error, price changes, unreliable partners, or weather conditions. That's nothing you can predict upfront (maybe except weather, to a degree), but those factors usually blow up construction projects. Not the fact that it suddenly took you three times as long to build this wall because you had to do it completely differently than before, and couldn't have known that.

An IT project is totally different. As the article states (and I agree), most of the work happens in terra incognito. I cannot reliably estimate what I don't know. Sure, there are situations where I can reliably estimate my work, but more often than not, I can't. Especially when the estimates go into weeks or months. There is no way to predict anything reliably for such a period of time, IMO.

Post reply on HN