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

51–60 of 326 posts

Re: How I estimate work

#51

Post by tayo42 »

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.

For any slightly complicated project on a house the estimate assumes everything goes right, which everyone knows it probably won't. It's just a starting point, not a commitment.

Re: How I estimate work

#52

Post by iamflimflam1 »

narmiouh wrote: post #42
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.

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…

Building a house, adding an extension, replacing a bathroom, building a deck. Many unknowns - you'd still expect an estimate.

Re: How I estimate work

#53

Post by tuna74 »

Falimonda wrote: post #31
tuna74 wrote: post #21

Slightly OT, but anyway. The only reasonable way to estimate something is in work hours. Everything else is severely misguided. Also, if you don't follow up any estimate is meaningless.

Work hours is the only way I've learned to think about it productively. It's also important to gather consensus among the team and understand if/why work hour estimates differ between individuals on the same body of work or tasks. I'd go so far as to say that a majority of project planning, scoping, and derisking can be figured out during an honest discussion about work hour estimates. Story points are too open to in…

If you have complex tasks and you have more than one person put in time to do a proper estimate, yes, you should sync up and see if you have different opinions or unclear issues.

Re: How I estimate work

#54

Post by somewhereoutth »

Features : Quality : Timeline

Choose 2. For example a large feature set can be made quickly, but it will be of poor quality.

Note that cost is somewhat orthogonal, throwing money at a problem does not necessarily improve the tradeoff, indeed sometimes it can make things worse.

Re: How I estimate work

#55

Post by danparsonson »

cvwright wrote: post #22
ripped_britches wrote: post #19

I don’t do a ton of estimation but an interesting new thing is asking a cli agent to estimate for you. First impressions with this is they give really long estimates. Also, due to coding agents, you can have them completely implement several different approaches and find a lot of unknown unknowns up front. I was building a mobile app and couldn’t figure out whether I wanted to do two native apps or one RN/Expo app. I…

I think Claude’s estimates are biased towards huge enterprise projects. I asked it to estimate a timeline for a feature in my hobby project and it confidently replied, “4.5 weeks to code completion”. Less than 4 hours later, the feature was done. I asked it to compare this against its initial estimate and it replied, “Right on schedule!” I have completely given up on using it to estimate anything that actually matter…

It's a next-word-prediction-machine, not a calculator. It's not aware of the passage of time, or how long things take, and doesn't reason about anything. It's just very good at putting words together in combinations that look like answers to your inputs.

That's really useful for some tasks, like regurgitating code to perform a specific function, but it's basically useless for jobs like estimating schedules.

Re: How I estimate work

#56

Post by iamflimflam1 »

Rotundo wrote: post #50
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.

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".

But the correct response to that is not - "I'm not going to tell you how long that will take" it's "let's work out what you are trying to accomplish".

Though the "I'm replacing your crew every three days" does cut a little too close the bone...

Re: How I estimate work

#57

Post by AnimalMuppet »

the_af wrote: post #32
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…

I think this is unfair to sales. I've made your argument before, but realistically, much of the word revolves around timelines and it's unreasonable to expect otherwise. When will you recover from your injury so you can play the world cup? When will this product arrive that I need for my child's birthday? When will my car be repaired, that I need for a trip? How soon before our competitors can we deliver this feature…

But it's the reality of engineering. If reality is unacceptable, that's not reality's problem.

But the problem is, the sales world has its own reality. The reality there is that "we don't know when" really is unacceptable, and "unacceptable" takes the form of lost sales and lost money.

So we have these two realities that do not fit well together. How do we make them fit? In almost every company I've been in, the answer is, badly.

The only way estimates can be real is if the company has done enough things that are like the work in question. Then you can make realistic (rough) estimates of unknown work. But even then, if you assign work that we know how to do to a team that doesn't know how to do it, your estimates are bogus.

Re: How I estimate work

#59

Post by loloquwowndueo »

pocketarc wrote: post #18
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…

I'm a dev, not a salesperson, but let's be realistic. A company tells you "yeah we're interested in signing at $1M/yr, but we really need this feature, when will you have it by?", to which saying "eh we don't know - it'll be done when it's done" will lead to the company saying "ok well reach out when you have it, we can talk again then" (or just "eh ok then not a good fit sorry bye"), and in the meantime they'll go s…

“Sign up and pay at least part of it now and we’ll prioritize the feature”.

I’ve seen enough instances of work being done for a specific customer that doesn’t then result in the customer signing up (or - once they see they can postpone signing the big contract by continuing to ask for “just one more crucial feature”, they continue to do so) to ever fall for this again.

Re: How I estimate work

#60

Post by iamflimflam1 »

tayo42 wrote: post #51
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.

For any slightly complicated project on a house the estimate assumes everything goes right, which everyone knows it probably won't. It's just a starting point, not a commitment.

Definitely so. Most business people that I've worked with do understand that. And provided problems are communicated early enough can manage expectations.

Where I've seen issues is when there is a big disconnect and they don't hear about problems until it's way too late.

Post reply on HN