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

161–170 of 326 posts

Re: How I estimate work

#161

Post by nradov »

threatofrain wrote: post #155
nradov wrote: post #150

Earlier quoted context omitted.

Software estimates for projects that don't involve significant technical risk can be made reliable, with sufficient discipline. Not all teams have that level of discipline but I've seen existence proofs of it working well and consistently. If you can't make firm delivery commitments to customers then they'll find someone who can. Losing customers, or not signing them in the first place, is the most harmful thing to e…

That assumes you’re working in some kind of agency or consulting environment where you repeatedly produce similar or even distinct things. As opposed to a product company that has already produced and is humming along, which is when most people get hired. Estimating the delivery of a product whose absence means zero product for the customer is very different. A company that’s already humming along can be slow on a fe…

Not at all. This can work fine in product development, as long as you limit the level of technical risk. On the other hand, if you're doing something really novel and aren't certain that it can work at all then making estimates is pointless. You have to treat it like a research program with periodic checkpoints to decide whether to continue / stop / pivot.

Re: How I estimate work

#163

Post by davnicwil »

RaftPeople wrote: post #147
davnicwil wrote: post #132

Earlier quoted context omitted.

With respect, I think this approach is actually harmful to everyone in the org because you're trying to twist reality to fit a premise that is just impossible to make true: that estimates of how long it takes to build software are reliable. The reluctance to accept the reality that it cannot be made true achieves nothing positive for anybody. Rather it results in energy being lost to heat that could otherwise be used…

> you're trying to twist reality to fit a premise that is just impossible to make true: that estimates of how long it takes to build software are reliable. It's not binary, it's a continuum. With experience, it's possible to identify whether the new project or set of tasks is very similar to work done previously (possibly many times) or if it has substantial new territory with many unknowns. The more similarity to pa…

Yes, but where reliability is concerned, a continuum is a problem. You can't say with any certainty where any given thing is on the continuum, or even define its bounds.

This is exactly what makes estimates categorically unreliable. The ones that aren't accurate will surprise you and mess things up.

In that sense, it does compress to being binary. To have a whole organisation work on the premise that estimates are reliable, they all have to be, at least within some pretty tight error bound (a small number of inaccuracies can be absorbed, but at some point the premise becomes de facto negated by inaccuracies).

Re: How I estimate work

#164

Post by flyingcircus3 »

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…

I think it comes down to the difference between predictions and prescriptions. When a person is predicting how long someone else's work will take, the revelation of their error causes them to change their subsequent predictions to be more accurate. When a person is prescribing how long someone else's work will take, the revelation of their error causes them to demand productivity increases.

Re: How I estimate work

#165

Post by pan69 »

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?

Re: How I estimate work

#166

Post by rajman187 »

i think it's worth revisiting this in a short while because, by and large, how the engineering craft has been for the last 40+ years is no longer the correct paradigm. it takes Claude Code a few moments to put together an entire proof of concept. engineers, especially experienced ones, will be less likely to produce (and hence be performance-calibrated on) code as output but rather orchestration and productionization of [a fleet of] agents. how do you guide an llm to produce exactly what is needed, based on your understanding of constraints, available libraries, various systems and APIs, etc. to accomplish some business or research goal?

in that sense, estimation should theoretically become a more reasonable endeavor. or maybe not, we just end up back where we are because the llm has produced unusable code or an impossible-to-find bug which delays shipment etc.

Re: How I estimate work

#167

Post by nradov »

state_less wrote: post #142
CuriouslyC wrote: post #89

Earlier quoted context omitted.

This is true, but the problem is that engineers are being asked to over-extrapolate given the evidence, and expected to own that extrapolation despite the paucity of evidence to make a good estimate. I *HATE* estimating roadmaps, because it feels unfair. I'm happy to estimate a sprint.

In another life, I would do things like measure the cost in developer time of bugs making it into developer repos vs. the cost in time of running tests in CI to catch such bugs, so evidence based decision making. It was mostly ignored, and at first I was surprised. A multi million dollar organization of people making negative EV plays, which I chalked up to the political pressures being more important than the wastag…

It's sad how software organizations refuse to learn from history. The US Navy was using PERT to manage huge, risky projects back in the 1950s with pretty good results. It can give you a Gaussian distribution of project completion dates based on best / middle / worst case estimates for individual tasks with dependencies.

https://en.wikipedia.org/wiki/Program_evaluation_and_review_...

Re: How I estimate work

#168

Post by firefoxd »

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 note on his monitor with the password written on it.

When we made all the necessary changes, the docker file failed to build. SRE accidentally deleted the deprecated image with PHP that had reached EOL.

Estimating is always fun.

Re: How I estimate work

#169

Post by nradov »

mikepurvis wrote: post #158
lubujackson wrote: post #151

Earlier quoted context omitted.

I agree whole-heartedly with the source article as well as this comment. The point is that the work of estimation is most of the work. We can have better estimates if we break things down to bite-sized chunks, but "when will this be done" is largely impossible and comes down to many external factors. Laypeople understand this implicitly in other contexts. My favorite metaphor is building something like a new shopping…

I've also seen it argued that real world estimates for things like construction projects are so good because 99% of it is do-overs from similar projects in the past; everyone knows what it takes to pour a column or frame a floor or hang a beam. Whereas with software most of what was done previously is now an import statement so up to 80-100% of the project is the novel stuff. Skilled leaders/teams know to direct upfr…

Real world estimates for construction projects are often way off. Especially for remodeling or renovation of older buildings, where the most serious problems can remain hidden until you get into the demolition phase.

Re: How I estimate work

#170

Post by nradov »

icedchai wrote: post #156
FINDarkside wrote: post #119

Earlier quoted context omitted.

I feel like some people in this thread are talking about estimates and some are talking about deadlines. Of course we should be able to give estimates. No, they're probably not very accurate. In many industries it makes sense to do whatever necessary to meet the estimate which has become a deadline. While we could do that in software, there often isn't any ramifications of going a bit overtime and producing much more…

The real problem is software teams being given deadlines without being consulted about any sort of estimates. "This needs to be done in 60 days." Then we begin trading features for time and the customer winds up getting a barely functioning MVP, just so we can say we made the deadline and fix all the problems in phase 2.

OK, so that sounds fine. Software delivers value to customers when it's better than nothing some of the time. Even if it barely functions then they're probably happier with having it than not, and may be willing to fund improvements.
Post reply on HN