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

41–50 of 326 posts

Re: How I estimate work

#41

Post by geetee »

iamflimflam1 wrote: post #28
bgribble wrote: post #12

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well. They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engin…

If you hired someone to do some work on your house, and they refused to give an estimate, would you be happy? If you had a deadline - say thanksgiving or something - and you asked “will the work be done by then” and the answer was “I’m not going to tell you” would you hire the person? The no estimates movement has been incredibly damaging for Software Engineering.

Most businesses like to pretend change orders don't apply to software.

Re: How I estimate work

#42

Post by narmiouh »

iamflimflam1 wrote: post #28
bgribble wrote: post #12

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well. They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engin…

If you hired someone to do some work on your house, and they refused to give an estimate, would you be happy? If you had a deadline - say thanksgiving or something - and you asked “will the work be done by then” and the answer was “I’m not going to tell you” would you hire the person? The no estimates movement has been incredibly damaging for Software Engineering.

Painting a wall has no “if then else”. You dont need to test to see if the wall has been painted.

I guess a fair analogy would be if the home owner just said “Make my home great and easy to use” by Thanksgiving without too many details, and between now ans thanksgiving refines this vision continuously, like literally changing the color choice half way or after fully painting a wall… then its really hard to commit.

If a home owner has a very specific list of things with no on the job adjustments, then usually you can estimate(most home contract work)

All software requests are somewhere in between former and latter, most often leaning towards the former scenario.

Re: How I estimate work

#43

Post by tuna74 »

geetee wrote: post #41
iamflimflam1 wrote: post #28

Earlier quoted context omitted.

If you hired someone to do some work on your house, and they refused to give an estimate, would you be happy? If you had a deadline - say thanksgiving or something - and you asked “will the work be done by then” and the answer was “I’m not going to tell you” would you hire the person? The no estimates movement has been incredibly damaging for Software Engineering.

Most businesses like to pretend change orders don't apply to software.

Then you need a new estimate. That is not hard to comprehend.

Re: How I estimate work

#44

Post by coffeebeqn »

Glyptodon wrote: post #24

I agree with most of things on this article with and additional caveat: estimates are also a function of who is going to do the work. If I have a team of 5 offshore devs who need hand holding, 2 seniors who are very skilled, and two mid level or juniors, how long something will take, what directions will be given, and even the best approach to choose can vary wildly depending on which subset of the team is going to b…

And how many other parallel work streams are going. So many times I’ve estimated something to be “5” and it’s gone into my queue. Then people are wondering why it’s not done after “5” estimation units have passed and I’ve got “10” points worth of more high priority tasks and fires at every moment of my career

Re: How I estimate work

#45

Post by tuna74 »

pluralmonad wrote: post #36
xyzzy123 wrote: post #29

Earlier quoted context omitted.

The top down push for timelines is because: In Australia, an SDE + overhead costs say $1500 / work day, so 4 engineers for a month is about $100k. The money has to be allocated from budgets and planned for etc. Dev effort affects the financial viability and competitiveness of projects. I feel like many employees have a kind of blind spot around this? Like for most other situations, money is a thing to be thought abou…

Doesn't this ignore the glaring difference between a plumbing task and a software task? That is, level of uncertainty and specification. I'm sure there are some, but I can't think of any ambiguous plumbing requirements on the level of what is typical from the median software shop.

How much plumbing knowledge do you have?

Re: How I estimate work

#46

Post by mactavish88 »

xyzzy123 wrote: post #29
bgribble wrote: post #12

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well. They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engin…

The top down push for timelines is because: In Australia, an SDE + overhead costs say $1500 / work day, so 4 engineers for a month is about $100k. The money has to be allocated from budgets and planned for etc. Dev effort affects the financial viability and competitiveness of projects. I feel like many employees have a kind of blind spot around this? Like for most other situations, money is a thing to be thought abou…

The only approach that genuinely works for software development is to treat it as a "bet". There are never any guarantees in software development.

1. Think about what product/system you want built.

2. Think about how much you're willing to invest to get it (time and money).

3. Cap your time and money spend based on (2).

4. Let the team start building and demo progress regularly to get a sense of whether they'll actually be able to deliver a good enough version of (1) within time/budget.

If it's not going well, kill the project (there needs to be some provision in the contract/agreement/etc. for this). If it's going well, keep it going.

Re: How I estimate work

#47

Post by paulddraper »

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.

Re: How I estimate work

#48

Post by tossandthrow »

IMHO time estimation for software development is a legacy way of thinking. A result of industrial processes.

At my team we think in terms of deliverables and commitments: "I can commit til deliver this by that date under these circumstances".

This mitigated the diverse nature Og thinking.

Re: How I estimate work

#49

Post by tuna74 »

coffeebeqn wrote: post #44
Glyptodon wrote: post #24

I agree with most of things on this article with and additional caveat: estimates are also a function of who is going to do the work. If I have a team of 5 offshore devs who need hand holding, 2 seniors who are very skilled, and two mid level or juniors, how long something will take, what directions will be given, and even the best approach to choose can vary wildly depending on which subset of the team is going to b…

And how many other parallel work streams are going. So many times I’ve estimated something to be “5” and it’s gone into my queue. Then people are wondering why it’s not done after “5” estimation units have passed and I’ve got “10” points worth of more high priority tasks and fires at every moment of my career

Excellent example why anything else than work hours is pointless to estimate in.

Re: How I estimate work

#50

Post by Rotundo »

iamflimflam1 wrote: post #28
bgribble wrote: post #12

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well. They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engin…

If you hired someone to do some work on your house, and they refused to give an estimate, would you be happy? If you had a deadline - say thanksgiving or something - and you asked “will the work be done by then” and the answer was “I’m not going to tell you” would you hire the person? The no estimates movement has been incredibly damaging for Software Engineering.

If work on a house was specified like a typical software project, no builder would even return your call.

"I'd like to have my roof reshingled, but with glass tiles and it should be in the basement, and once you are half way I'll change my mind on everything and btw, I'm replacing your crew every three days".

Post reply on HN