How I estimate work • Hacker News Board

Re: How I estimate work

#151

Post by lubujackson » Sat, Jan 24, 2026, 6:53 PM UTC

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…

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 mall. If you ask for an estimate you first need to architect the entire thing. This is equivalent to breaking down the task into sprints. In most companies the entire architecture phase is given very little value, which is insane to me.

Once we have our blueprints, we have other stakeholders, which is where things really go off the rails. For the mall, maybe there is an issue with a falcon that lives on the land and now we need to move the building site, or the fixtures we ordered will take 3 extra months to be delivered. This is the political part of estimating software and depends a lot on the org itself.

Then, finally building. This is the easy part if we cleared the precursor work. Things can still go wrong: oops we hit bedrock, oops a fire broke out, oos the design wasn't quite right, oops we actually want to change the plan.

But yes, estimates are important to businesses. But businesses have a responsibility to compartmentalize the difference. Get me to a fully ticketed and approved epic and most engineers can give you a pretty good estimate. That is what businesses want, but they consider the necessary work when they Slack you "how long to build a mall?"

Re: How I estimate work

#152

Post by khendron » Sat, Jan 24, 2026, 6:54 PM UTC

When I was in grad school my faculty advisor joked to me that to accurately estimate any medium to large software project, take your best estimate and multiply it by 3. If hardware is involved, multiply by 8.

Yes, he was telling me this tongue in cheek, but in my actual experience this has been eerily accurate.

Re: How I estimate work

#153

Post by nradov » Sat, Jan 24, 2026, 7:01 PM UTC

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…

The most effective approach that I've found to prevent delays in large scale software projects is to carve out a dedicated team to deal with critical bugs, L3 support tickets, and urgent minor enhancements. Don't count them in capacity planning. They serve to insulate the feature teams from distractions. Rotate those assignments for each project so that everyone takes a turn.

Re: How I estimate work

#154

Post by loloquwowndueo » Sat, Jan 24, 2026, 7:02 PM UTC

wreath wrote: post #126

loloquwowndueo wrote: post #59

Earlier quoted context omitted.

“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?

If the competitor already has it why are you talking to me? :)

Re: How I estimate work

#155

Post by threatofrain » Sat, Jan 24, 2026, 7:03 PM UTC

nradov wrote: post #150

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…

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 feature and customers wouldn’t even know. A company that’s not already humming is still trying to persuade customers that they deserve to not die.

Re: How I estimate work

#156

Post by icedchai » Sat, Jan 24, 2026, 7:03 PM UTC

FINDarkside wrote: post #119

PxldLtd wrote: post #96

Earlier quoted context omitted.

Sounds like you don't have a good process for handling scope changes. I should know, the place I'm at now it's lacklustre and it makes the job a lot harder. Usually management backs off if they have a good understanding of the impact a change will make. I can only give a good estimate of impact if I have a solid grip on the current scope of work and deadlines. I've found management to be super reasonable when they ac…

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.

Re: How I estimate work

#157

Post by dxdm » Sat, Jan 24, 2026, 7:04 PM UTC

publicdebates wrote: post #8

> I ask myself "which approaches could be done in one week?". This is exactly how all good art is done. There's an old French saying, une toile exige un mur.

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

Re: How I estimate work

#158

Post by mikepurvis » Sat, Jan 24, 2026, 7:05 PM UTC

lubujackson wrote: post #151

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…

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 upfront effort toward exploring the least understood parts of the plan to help reduce down-stream risk but to really benefit from that instinct the project plan has to regularly incorporating its findings.

Re: How I estimate work

#159

Post by wreath » Sat, Jan 24, 2026, 7:12 PM UTC

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 a project might take, and you can confidence intervals like 90% confidence we finish this in 3 months, 70% confidence we finish it in 10 weeks, 50% confidence in 6 weeks and 10% confidence we finish it in 2 weeks.

IMO this is also a better way to communicate with stakeholders outside the team instead of committing to a specific date. It gives more context and clearly communicates that this is a probability game after all since there are quite few moving variables.

Re: How I estimate work

#160

Post by lucketone » Sat, Jan 24, 2026, 7:18 PM UTC

davnicwil wrote: post #132

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…

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…

There is an enterprise methodology that increases precision of project estimation.

1. Guess the order of magnitude of the task (hours vs days/months/years)

2. Add known planning overhead that is almost order of magnitude more.

Example: if we guess that task will take 30min, but actually it took 60min - that’s 100% error (30min error/30min estimate).

But if the methodology is used correctly, and we spend 2h in a planning meeting, same estimate and same actual completion time results in only 20% error, because we increased known and reliable part of the estimate (30min error / 2h30min estimate)