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

191–200 of 326 posts

Re: How I estimate work

#191

Post by publicdebates »

wiether wrote: post #188
dxdm wrote: post #157

Earlier quoted context omitted.

> No results found for "une toile exige un mur". In case anyone else is wondering: The French phrase can be translated literally as "a canvas requires a wall", or less closely, "its boundaries are important for every picture". (I am not a native French speaker and just piecing this together with a dictionary.)

French guy here: never heard of "une toile exige un mur". Not a single result in French also. I know there's a (more popular?) saying that is very similar but can't remember it atm.

Are you sure? I thought it was Renoir or Batut, or Bresson, or perhaps Watteau, who, when asked for his most useful advice to a new artist, famously uttered this short and mysterious phrase. Could have sworn LaBeouf quoted it in an interview after he collaborated with artist Cantor on their magnum opus.

Re: How I estimate work

#192

Post by scott_w »

xn wrote: post #71

Is it going to take more than two hours? Is it going to take more than two days? Is it going to take more than two weeks? Is it going to take more than two months? Is it going to take more than two years? If you can answer these questions, you can estimate using a confidence interval. If the estimate is too wide, break it down into smaller chunks, and re-estimate. If you can't break it down further, decide whether it…

There’s also something more concrete about asking “Can you get it done by end of tomorrow? What does that require?”

I prefer it over estimating which feels more like asking the length of a piece of string.

Re: How I estimate work

#193

Post by boltzmann-brain »

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.

Re: How I estimate work

#194

Post by boltzmann-brain »

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…

> who have to put up with us

this kind of (self-)deprecation is exactly the kind of thing that makes it impossible to be happy as a technical person in a startup

Re: How I estimate work

#195

Post by bitwize »

> This is, of course, false. As every experienced software engineer knows, it is not possible to accurately estimate software projects.

Hogwash. Has this person never run a business, or interacted with those who have? The business depends on estimates in order to quantitatively determine how much time, money, and resources to allocate to a project. Teams in the manufacturing and construction fields deliver estimates all the time. Why shouldn't IT people be held to the same standard?

If you can't estimate, it's generally because your process isn't comprehensive enough. Tim Bryce said it's very straightforward, once you account for all the variables, including your bill of materials (what goes into the product), and the skill level and effectiveness rating (measured as the ratio of direct work to total time on the job) of the personnel involved. (You are tracking these things, aren't you?)

https://www.modernanalyst.com/Resources/Articles/tabid/115/I...

> The pro-estimation dogma says that these questions ought to be answered during the planning process, so that each individual piece of work being discussed is scoped small enough to be accurately estimated. I’m not impressed by this answer. It seems to me to be a throwback to the bad old days of software architecture, where one architect would map everything out in advance, so that individual programmers simply had to mechanically follow instructions.

If you're not dividing the work such that about ~60% of the time is spent in analysis and design and only ~15% in programming, you've got your priorities backwards. In the "bad old days", systems got delivered on time and under budget, and they shipped in working order, rather than frustrating users with a series of broken or half-working systems. This is because PRIDE, the scientific approach to systems analysis and design, was the standard. It still is in places like Japan. Not so much America, where a lot of software gets produced it's true, but very little of it is any good.

Re: How I estimate work

#196

Post by alexmonami »

crazygringo wrote: post #174

Not a single mention of planning poker and story points? They're not perfect (nothing is), but they're actually pretty good. Every task has to be completable within a sprint. If it's not, you break it down until you have a part that you expect is. Everyone has to unanimously agree on how many points a particular story (task) is worth. The process of coming to unanimous agreement is the difficult part, and where the r…

Our small team uses the Fibonacci sequence to estimate, and it works well for us.

Re: How I estimate work

#197

Post by Fire-Dragon-DoL »

crazygringo wrote: post #174

Not a single mention of planning poker and story points? They're not perfect (nothing is), but they're actually pretty good. Every task has to be completable within a sprint. If it's not, you break it down until you have a part that you expect is. Everyone has to unanimously agree on how many points a particular story (task) is worth. The process of coming to unanimous agreement is the difficult part, and where the r…

Because story points MUST be specific per person based on the smallest task they ever faced, they cannot be summed up because they are not units, and points do not translate to time, we cannot talk about story points.

Sorry if it comes through as rude, but this is how I keep repeatedly being told story points work.

If you look at all those properties together, story points are completely useless.

The only moment time it makes sense is when you have a SHARED understanding of the smallest point AND you can translate it to time. When you do that, story points are useful. Also, they become time, so there is no reason to use points.

Re: How I estimate work

#198

Post by lucketone »

theptip wrote: post #144
etamponi wrote: post #88

Earlier quoted context omitted.

> But plenty can be estimated more accurately. As a person that has never encountered a complex software project that can be accurately estimated, I am being a bit skeptical. The author did make examples of when estimation is possible: easy projects with a very short time horizons (less than an a couple of days, I'd say). I'd love to hear some examples of more complex software projects that can be estimated within a…

> easy projects with a very short time horizons (less than an a couple of days, I'd say). The example I quoted said hours, not days. But even taking your claim of days as estimable, I have seen much better. An example of weeks-long projects I regularly estimate accurately would be things like “in our Django monolith, add this new field/model, and update the state machine with these new transitions, and update the API…

> An example of year-long projects I have seen waterfall’d successfully are IP protocol implementations where the RFC is clear, base frameworks exist, and the org has engineers with decades of individual experience implementing protocols in the same framework.

Article responds to you with:

“For most of us, the majority of software work is not like this. We work on poorly-understood systems and cannot predict exactly what must be done in advance. Most programming in large systems is research…”

It is good to target the strongest point, not the weakest.

Re: How I estimate work

#199

Post by spike021 »

crazygringo wrote: post #174

Not a single mention of planning poker and story points? They're not perfect (nothing is), but they're actually pretty good. Every task has to be completable within a sprint. If it's not, you break it down until you have a part that you expect is. Everyone has to unanimously agree on how many points a particular story (task) is worth. The process of coming to unanimous agreement is the difficult part, and where the r…

I've been on teams that tried various methods of estimating and the issue I always encounter is that everyone estimates work differently, but usually people will side with the person with the most context.

For instance someone says a ticket is two days' work. For half the team that could be four days because people are new to the team or haven't touched that codebase, etc. But because the person who knows the ticket and context well enough says 2, people tend to go with what they say.

We end up having less of those discussions you describe to come to an agreement that works more on an average length of time the ticket should take to complete.

And then the org makes up new rules that SWEs should be turning around PRs in less than 24 hours and if reviews/iterating on those reviews takes longer than two days then our metrics look bad and there could be consequences.

But that's another story.

Re: How I estimate work

#200

Post by danenania »

AlotOfReading wrote: post #85
chrisfosterelli wrote: post #68

Earlier quoted context omitted.

I agree. Software engineering is basically the only industry that pretends this is professionally acceptable. Imagine if government staff asked when a bridge would be done or how much it would cost and the lead engineer just said "it's impossible to estimate accurately, so we wont. It's a big project tho". Estimating in software is very hard, but that's not a good reason to give up on getting better at it

Contractor estimates are just as prone to schedule slippage and cost overruns as anything estimated by software engineers. I doubt anyone's ever argued that giving wrong estimates is hard or impossible. Only that approximately correct ones are, and other industries seem to struggle with that just as much as software. Authors don't finish books by deadlines, so fans are left in the cold. Tunnels take twice as long and…

The date is just a useful fiction to:

- Create urgency

- Keep scope creep under control

- Prioritize whatever is most valuable and/or can stand on its own

If you just say “I don’t know” and have no target, even if that’s more honest, the project is less likely to ever be shipped at all in any useful form.

Post reply on HN