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

271–280 of 326 posts

Re: How I estimate work

#271

Post by csours »

pan69 wrote: post #165
wreath wrote: post #159

What often baffles me with engineers and especially engineering managers is that they don't derive the estimates from metrics of prior projects, especially for long running teams (as opposed to project teams). You don't need to estimate down to the minute, but you already know how many tickets/work items the completes at a given time interval with how many people in the team etc. This should give a rough estimate of…

How long does it take to do a crossword puzzle or play a game of chess?

How long does it take to solve a Rubik's cube for the first time?

How long does it take to learn to juggle 3 items? 4? 5?

How much time will it take you to measure the coast of England between Brighton and Seaton?

Re: How I estimate work

#272

Post by cryptonector »

HEmanZ wrote: post #138

Whenever this comes up I feel like I work on completely different kinds of software than most people here. (Giant, backend, distributed systems projects at FAANG) I’ve never worked on anything large in software where the time it will take can be reasonably deduced at the accuracy some people here seem to assume possible. The amount of unknown-unknowns is always way way too large and the process of discovery itself ex…

I've worked on codebases all the way tens of millions of lines of code. Obviously not in the sense of knowing all the dusty corners of such codebases, but still, I did enough work on them that I had to navigate my way around millions of loc. It's not easy! The problem is that you can't possibly know even a sizeable fraction of such a codebase well. Instead you can know small corners well and know your way around the internal and external interfaces so you can find gotchas and answer questions as you research. The knowledge you build is hard to communicate to others, too, so bringing others up to speed is not easy either. So for me TFA hits all the right notes.

But I've also seen things like the ZFS team at Sun deliver something unbelievably good that started as a skunkworks project that senior management didn't really know about until there was enough to show to justify a large investment. Sun was like DARPA: not micromanaged from the top. Sun failed, of course, but not because of this.

Re: How I estimate work

#274

Post by cryptonector »

firefoxd wrote: post #168

We estimated a single sprint to move from our plain text passwords. Easy! Add a new field in the db for secure pass, and one to force password update. Update the api to take the new fields into account... It took 6 months. Why? Well it was a legacy app, and we learned that passwords were case insensitive because the customer sent a video of him entering his password that failed. On the video, we could see a sticky no…

Oof. Exactly. Simple things get complicated when you find out that there were unstated requirements, hidden booby traps, etc. And then there's random interrupts -- unrelated stuff that comes up and takes your time and focus. If you run a lean ship then interrupt management is critical, but ideally you can have a few people who are understood to take critical interrupts and thus their schedules will slip.

Re: How I estimate work

#275

Post by mitthrowaway2 »

crazygringo wrote: post #258
netghost wrote: post #253

Earlier quoted context omitted.

I worked on a product that was built around planning an estimation with ranged estimates (2-4h, 1-3d, etc) 2-12d conveys a very different story than 6-8d. Are the ranges precise? Nope, but they're useful in conveying uncertainty, which is something that gets dropped in any system that collapses estimates to a single point. That said, people tend to just collapse ranges, so I guess we all lose in the end.

> 2-12d conveys a very different story than 6-8d. In agile, 6-8d is considered totally reasonable variance, while 2-12d simply isn't permitted. If that's the level of uncertainty -- i.e. people simply can't decide on points -- you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing once you have a more accurate estimate. You would never just blindly d…

If you measure how long a hundred "3-day tasks" actually take, in practice you'll find a range that is about 2-12. The variance doesn't end up getting de-risked. And it doesn't mean the 3-day estimate was a bad guess either. The error bars just tend to be about that big.

Re: How I estimate work

#276

Post by Magmalgebra »

crazygringo wrote: post #238
Magmalgebra wrote: post #234

Earlier quoted context omitted.

> is in points not days I hear this often, but I've never met someone for whom points didn't eventually turn into a measurement of time - even using the exact process you're describing. I think any process that's this hard to implement should be considered bad by default, barring some extraordinary proof of efficacy.

> I've never met someone for whom points didn't eventually turn into a measurement of time The goal isn't to avoid time estimation completely, that would be crazy. People estimate how many points get delivered per sprint and sprints have fixed lengths of time. You can do the math, you're supposed to. The point is that points avoid a false sense of precision: https://news.ycombinator.com/item?id=46748310 The process i…

> The process is quite easy to implement

Having implemented it myself, I agree it is easy to implement. My argument is that it is overly difficult to maintain. My experience is that incentives to corrupt the point system are too high for organizations to resist.

Funnily enough - I work closely with a former director of engineering at Atlassian (the company whose guide you cite) and he is of the opinion that pointing had become "utterly dishonest and a complete waste of time". I respect that opinion.

If you have citations on pointing being effective I'd be very interested. I consider myself reasonably up to date on SWE productivity literature and am not aware of any evidence to that point - I have yet to see it.

Re: How I estimate work

#277

Post by n4r9 »

crazygringo wrote: post #212
n4r9 wrote: post #201

Earlier quoted context omitted.

What is the benefit of estimating points rather than days? Feels like you're still ultimately estimating days in the end.

Because, for whatever psychological reason, estimating in time leads to a false sense of accuracy, people pointlessly argue over whether something will take 5 days vs. 6, and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc. Estimating in points that are basically a Fibonacci sequence keep estimation precision limited and avoids implying false guarantees. Yes, in t…

Can't you do that by just limiting the precision? You can only vote 1, 2, 3, 5 or 8 days. Not sure what "points" are adding. As far as I can tell, it's an attempt to account for estimation difficulties by introducing a "velocity" concept. But I think it makes things more complex without actually solving the issue.

Re: How I estimate work

#278

Post by bonesss »

ptmcc wrote: post #267
mmcnl wrote: post #175

I don't get the fight against estimates. An estimate is an estimate. An estimate can be wrong. It likely is wrong, that's fine, it doesn't have to be perfect. There is a confidence interval. You can communicate that. Very often something like "6-12 months" is a good enough estimate. I've worked in software a long time and I really don't get why many people think it's impossible to give such an estimate. Most of us ar…

You've never had a manager or product person take estimates, even clearly communicated as low confidence or rife with unknowns, as gospel truth? Lucky you.

Engineer: “It will take me two days [of work].” Sales:”We will have your fix ready in three calendar days [today + 2].”

Actual work that week gives employee 3 hours of non-meeting time, each daily meeting adds 0.5 hours of high-urgency administrative work. Friday’s we have a mandatory all-hands town halls…

Repeat that cycle for every customer facing issue, every demo facing issue, and internal political issue and you quickly drive deep frustrations and back talking.

I think there’s a fundamental truth: no one in their right minds, not even motivated engineers, actually hears anything but calendar when getting “days” estimates. It’s a terrible misrepresentation almost all the time, and engineers do a disservice when they yield to pressure to deliver them outside the broader planning process.

Project schedules should be the only place that time commitments come from, since they’re informed with necessary resource availability.

Re: How I estimate work

#279

Post by scott_w »

alfiedotwtf wrote: post #255
scott_w wrote: post #192

Earlier quoted context omitted.

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.

The problem I have is, conceptually a task always looks easy, but then as your coding, you hit several problems that are not simple to overcome - in fact, lot of times these issues turn into almost insolvable problems that blow out any time estimates ;(

That’s why time limiting rather than estimating works for me. It forces me to contend with the question: “can I get this done today?” That’s usually an easier question to answer because it’s to tightly time bound. I’m not always correct but I’ll know tomorrow if I wasn’t, rather than next month!

When I’m asked on longer time frames, I’m much less confident but it’s still more concrete than the other way around.

Re: How I estimate work

#280

Post by wesselbindt »

HEmanZ wrote: post #138

Whenever this comes up I feel like I work on completely different kinds of software than most people here. (Giant, backend, distributed systems projects at FAANG) I’ve never worked on anything large in software where the time it will take can be reasonably deduced at the accuracy some people here seem to assume possible. The amount of unknown-unknowns is always way way too large and the process of discovery itself ex…

https://thestory.is/en/journal/chaos-report/

^ This report from 2020 analyzed about 50,000 IT projects in a wide range of market segments, and they found that 50% exceeded their deadline. This seems to suggest that your conclusion holds more generally than just your specific context.

On a personal level, I hardly ever see a developer's estimate turn out to be right, on whatever scale. I'm wondering what the pro estimate folks in this thread work on that they're able to estimate accurately.

Post reply on HN