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

71–80 of 326 posts

Re: How I estimate work

#71

Post by xn »

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's worth spending time to gather information needed to narrow the estimate or break it down. If not, scrap the project.

Re: How I estimate work

#72

Post by xyzzy123 »

pluralmonad wrote: post #36
xyzzy123 wrote: post #29

Earlier quoted context omitted.

The top down push for timelines is because: In Australia, an SDE + overhead costs say $1500 / work day, so 4 engineers for a month is about $100k. The money has to be allocated from budgets and planned for etc. Dev effort affects the financial viability and competitiveness of projects. I feel like many employees have a kind of blind spot around this? Like for most other situations, money is a thing to be thought abou…

Doesn't this ignore the glaring difference between a plumbing task and a software task? That is, level of uncertainty and specification. I'm sure there are some, but I can't think of any ambiguous plumbing requirements on the level of what is typical from the median software shop.

Sorry, I edited the plumbing refence out of my comment because I saw a sibling post that made a similar point.

I agree there is less uncertainty in plumbing - but not none. My brother runs a plumbing company and they do lose money on jobs sometimes, even with considerable margin. Also when I've needed to get n quotes, the variation was usually considerable.

I think one big situational difference is that my brother is to some extent "on the hook" for quotes (variations / exclusions / assumptions aside) and the consequences are fairly direct.

Whereas as an employee giving an estimate to another department, hey you do your best but there are realistically zero consequences for being wrong. Like maybe there is some reputational cost? But either me or that manager is likely to be gone in a few years, and anyway, it's all the company's money...

Re: How I estimate work

#73

Post by dorn64 »

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…

It all starts with sales and marketing cramming every possible feature and half-rumour they heard about competitors' features into a 6 month project deadline. That's a long time, 6 months, no? How hard can it be? Respectfully, it'll be done when it's done.

Re: How I estimate work

#74

Post by the_af »

AnimalMuppet wrote: post #57
the_af wrote: post #32

Earlier quoted context omitted.

I think this is unfair to sales. I've made your argument before, but realistically, much of the word revolves around timelines and it's unreasonable to expect otherwise. When will you recover from your injury so you can play the world cup? When will this product arrive that I need for my child's birthday? When will my car be repaired, that I need for a trip? How soon before our competitors can we deliver this feature…

But it's the reality of engineering . If reality is unacceptable, that's not reality's problem. But the problem is, the sales world has its own reality. The reality there is that "we don't know when" really is unacceptable, and "unacceptable" takes the form of lost sales and lost money. So we have these two realities that do not fit well together. How do we make them fit? In almost every company I've been in, the ans…

I don't know that it's the reality of engineering. (Edit: in fact there are some comments for this post providing counterexamples, an interesting one is the hardware world).

It's what we software engineers like to tell ourselves because it cuts us slack and shifts the blame to others for budget and time overruns. But maybe it's also our fault and we can do better?

And the usual argument of "it's not like physical engineering, software is about always building something new" because that's only true for a minority of projects. Most projects that fail or overrun their limits are pretty vanilla, minor variations of existing stuff. Sometimes just deploying a packaged software with minor tweaks for your company (and you must know this often tends to fail or overrun deadlines, amazingly).

I know another "engineering" area where overruns are unacceptable to me and I don't cut people slack (in the sense it's me who complains): home building/renovation contractors. I know I'm infuriated whenever they pull deadlines out of their asses, and then never meet them for no clear reason. I know I'm upset when they stumble over the slightest setbacks, and they always fail to plan for them (e.g. "we didn't expect this pipe to run through here", even though they've done countless renovations... everything is always a surprise to them). I know I'm infuriated when they adopt the attitude of "it'll be done when it's done" (though usually they simply lie about upfront deadlines/budgets).

Maybe that's how others see us from outside software engineering. We always blame others, we never give realistic deadlines, we always act surprised with setbacks.

Re: How I estimate work

#75

Post by the_arun »

danparsonson wrote: post #55
cvwright wrote: post #22

Earlier quoted context omitted.

I think Claude’s estimates are biased towards huge enterprise projects. I asked it to estimate a timeline for a feature in my hobby project and it confidently replied, “4.5 weeks to code completion”. Less than 4 hours later, the feature was done. I asked it to compare this against its initial estimate and it replied, “Right on schedule!” I have completely given up on using it to estimate anything that actually matter…

It's a next-word-prediction-machine, not a calculator. It's not aware of the passage of time, or how long things take, and doesn't reason about anything. It's just very good at putting words together in combinations that look like answers to your inputs. That's really useful for some tasks, like regurgitating code to perform a specific function, but it's basically useless for jobs like estimating schedules.

I don’t disagree. But have you tried estimation using Claude or Cursor? If not, give it a try.

Re: How I estimate work

#76

Post by xyzzy123 »

mactavish88 wrote: post #46
xyzzy123 wrote: post #29

Earlier quoted context omitted.

The top down push for timelines is because: In Australia, an SDE + overhead costs say $1500 / work day, so 4 engineers for a month is about $100k. The money has to be allocated from budgets and planned for etc. Dev effort affects the financial viability and competitiveness of projects. I feel like many employees have a kind of blind spot around this? Like for most other situations, money is a thing to be thought abou…

The only approach that genuinely works for software development is to treat it as a "bet". There are never any guarantees in software development. 1. Think about what product/system you want built. 2. Think about how much you're willing to invest to get it (time and money). 3. Cap your time and money spend based on (2). 4. Let the team start building and demo progress regularly to get a sense of whether they'll actua…

How would you decide between doing project (a) this quarter, or project (b)?

If you cannot (or refuse to) estimate cost or probability of success in a timebox you have no way to figure out ROI.

To rationally allocate money to something, someone has to do the estimate.

Re: How I estimate work

#77

Post by replygirl »

dorn64 wrote: post #73
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…

It all starts with sales and marketing cramming every possible feature and half-rumour they heard about competitors' features into a 6 month project deadline. That's a long time, 6 months, no? How hard can it be? Respectfully, it'll be done when it's done.

we are the ones qualified to say what needs to be cut to provide reasonable certainty for the deadline. it is not the job of non-technical stakeholders to mitigate risk in technical projects

Re: How I estimate work

#78

Post by oakashes »

This is all helpful but I felt like it skipped past a critical part - how do you "extract the range my manager is looking for"? Presumably your manager has to stick to the polite fiction that estimates are a bottoms-up process, so what questions do you find helpful to get a sense of the number your manager/leadership team had in mind?

Re: How I estimate work

#79

Post by moregrist »

Rotundo wrote: post #50
iamflimflam1 wrote: post #28

Earlier quoted context omitted.

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.

If work on a house was specified like a typical software project, no builder would even return your call. "I'd like to have my roof reshingled, but with glass tiles and it should be in the basement, and once you are half way I'll change my mind on everything and btw, I'm replacing your crew every three days".

Sure, for roofing jobs or other large repairs, that’s true. But for remodeling it’s pretty different.

When I’ve engaged with a contractor for remodeling, I usually have some vague idea like “we should do something about this porch and deck and we’d like it to look nice.”

The contractor then talks to you about _requirements_, _options_, and _costs_. They then charges for architectural plans and the option to proceed with a budget and rough timeline.

Then they discover problems (perhaps “legacy construction”) and the scope creeps a bit.

And often the timeline slips by weeks or months for no discernible reason.

Which sounds exactly like a lot of software projects. But half of your house is torn up so you can’t easily cut scope.

Re: How I estimate work

#80

Post by saghm »

> For instance, many engineering teams estimate work in t-shirt sizes instead of time, because it just feels too obviously silly to the engineers in question to give direct time estimates. Naturally, these t-shirt sizes are immediately translated into hours and days when the estimates make their way up the management chain.

I've worked on multiple teams at completely different companies years apart that had the same weird rules around "story points" for JIRA: Fibbonacci numbers only, but also anything higher than 5 needs to be broken into subtasks. In practice, this just means, 1-5, except not 4. I have never been able to figure out why anyone thought this actually made any practical sense, or whether this apparently is either common enough to have been picked up by both teams or if I managed to somehow encounter two parallel instances of these rules developing organically.

Post reply on HN