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

121–130 of 326 posts

Re: How I estimate work

#121

Post by bsoles »

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.

Anybody who worked with a local contractor knows that their estimate and the reality has no correlation.

When you ask for a firm estimate, you are basically asking to be lied to, and the contractor happily complies by telling you a lie.

Re: How I estimate work

#122

Post by Phlebsy »

bluGill wrote: post #69
notjustanymike wrote: post #34

After owning a product, I've developed a lot of sympathy for the people outside of engineering who have to put up with us. Engineers love to push back on estimates, believing that "when it's done" is somehow acceptable for the rest of the business to function. In a functioning org, there are lot of professionals depending on correct estimation to do their job. For us, an accurate delivery date on a 6 month project wa…

> Trim features, push date, bring in extra help, or crunch. There are problems with all of these. The company knows they can sell X of the product for $Y (often X is a bad guess, but sometimes it has statistical range - I'll ignore this for space reasons but it is important!). X times Y equals gross profit. If the total costs to make the feature are too high the whole shouldn't be done. If you trim features - the aff…

I would settle for accurate estimates being a requirement if sticking to the estimate and allocations is as well. Every project I've been a part of that has run over on timeline or budget had somebody needling away at resources or scope in some way. If you need accuracy to be viable, then the organization cannot undermine the things that make it possible to stay on track.

Re: How I estimate work

#123

Post by tiberriver256 »

How do people get to "staff" without reading industry core reading?

Software Estimation: Demystifying the black art by Steve McConnell should be 1st year reading in any software development major in college...

We've largely "solved" this problem in the industry we just have a problem of getting people to read and read the right things

Re: How I estimate work

#124

Post by fogzen »

etamponi wrote: post #92

I think this post unveils a great truth that I never grasped: estimates are a political tool to decide what gets done and what doesn't get done. Thanks for putting it so nicely! One thing that I'd like to understand then is _why_... Why doesn't management use a more direct way of saying it? Instead of asking for estimates, why don't they say: we have until date X, what can we do? Is it just some American way of being…

I think because capitalist employment is inherently adversarial. If employers (and managers) reveal the time budget, employees may take advantage and reduce output to expand to fill the deadline. Tight schedules squeeze employees, so hiding the real time constraint allows management to exert pressure by adjusting the deadline. Employees that realize the bluff and ignore fake schedule pressure can be identified, marginalized, and eliminated.

Avoiding this degrading game is half the reason I preferred contracting.

Re: How I estimate work

#125

Post by moregrist »

bluGill wrote: post #69
notjustanymike wrote: post #34

After owning a product, I've developed a lot of sympathy for the people outside of engineering who have to put up with us. Engineers love to push back on estimates, believing that "when it's done" is somehow acceptable for the rest of the business to function. In a functioning org, there are lot of professionals depending on correct estimation to do their job. For us, an accurate delivery date on a 6 month project wa…

> Trim features, push date, bring in extra help, or crunch. There are problems with all of these. The company knows they can sell X of the product for $Y (often X is a bad guess, but sometimes it has statistical range - I'll ignore this for space reasons but it is important!). X times Y equals gross profit. If the total costs to make the feature are too high the whole shouldn't be done. If you trim features - the aff…

> This is why COMPANIES NEED ACCURATE ESTIMATES. They are not optional to running a company.

Sure, but even accurate estimates are only accurate as long as the assumptions hold.

Market conditions change, emergency requests happen, people leave, vendor promises turn out to be less than accurate.

And most estimates for non-routine work involve some amount of risk (R&D risk, customer risk, etc.).

So pounding the table and insisting on ACCURATE ESTIMATES without a realistic backup plan isn’t good business, it’s just pushing the blame onto the SWE team when (not if) something goes south.

Re: How I estimate work

#126

Post by wreath »

loloquwowndueo wrote: post #59
pocketarc wrote: post #18

Earlier quoted context omitted.

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.

Why do that if your competitor already has it? I'd just go talk to the competitor instead. If you aren't able to ballpark when the feature will be done, why should I trust you will once I pay part of the price?

Re: How I estimate work

#127

Post by tree888 »

tiberriver256 wrote: post #123

How do people get to "staff" without reading industry core reading? Software Estimation: Demystifying the black art by Steve McConnell should be 1st year reading in any software development major in college... We've largely "solved" this problem in the industry we just have a problem of getting people to read and read the right things

What do you mean “how”? Levels aren’t like building a bridge, it’s just arbitrary stuff. Even money is arbitrary, we’ve got Bitcoin billionaires after all.

As for reading… https://thecodelesscode.com/case/215?topic=documentation

Re: How I estimate work

#128

Post by nickevante »

This discussion on software estimation brings up an interaction I had with an engineer who optimized Black & Decker assembly lines in 1981 using an Apple II.

They didn't estimate in 'Story Points'. They used atomic physical constraints.

He described it like this:

There was a standardized metric for all manual operations like "reach, one hand, 18-24 inches" or "pick item 10-100g." Each step had a time in decimal seconds... The objective was to minimize the greatest difference in station time so that no line worker is waiting.

The most interesting part was his conclusion on the result: Modern supply management is a miracle, but manual labor today is much harsher... The goal back then was flow; the goal now is 100% utilization.

It feels like in software, we are moving toward that "100% utilization" model (ticket after ticket) and losing the slack that made the line work.

Re: How I estimate work

#129

Post by andychiare »

> It is not possible to accurately estimate software work.

An "accurate estimation" is an oxymoron. By definition, an estimate is imprecise. It only serves to provide an idea of the order of magnitude of something: will this work take hours? days? weeks? months? You can't be more accurate. And this does not apply only to software development.

Re: How I estimate work

#130

Post by theptip »

funrep wrote: post #84
theptip wrote: post #67

> This is, of course, false. As every experienced software engineer knows, it is not possible to accurately estimate software projects. This is a cop-out. Just because you can’t do it, doesn’t mean it’s impossible :) There are many types of research and prototyping project that are not strongly estimable, even just to p50. But plenty can be estimated more accurately. If you are building a feature that’s similar to so…

Did you read the article? They go on explain how you actually do it, in a very reasonable way.

Hi! “Did you read the article” is generally not in compliance with the HN community guidelines. Please don’t do this.
Post reply on HN