Hacker News new | ask | show | jobs
by leepowers 1178 days ago
OP is working in a dysfunctional workplace and has conflated that with "developer estimates are bad":

> 1. Give a very wide estimate with a lot of padding > 2. Get pressured to be more accurate and to bring the estimate down > 3. Get pressured to work unpaid overtime to meet that estimate > 4. Watch management get congratulated by upper management for running a tight ship

Imagine I had plumber at my house and he gave an estimate of 3 to 4 hours to replace a rusted pipe. And I responded with "I think it should only take you 1 hour". He would look at me like I was crazy. That's because trying to substitute my layman's estimate for a professional estimate is crazy.

OP is providing estimates - that's a reasonable ask. The problem is management is ignoring the professional estimate and using their position to substitute in their preferred estimate. OP is being used to launder management's expectations. So of course they're patting themselves on the back. If the plumber ignored his own professional experience and only charged me for 1 hour of labor I would think of highly of myself as well, even though in reality I had no idea what I was talking about.

The solution is to set estimates that you can explain and justify. If management ignores your professional opinion you need to make it clear it's their decision and not yours. If you don't respect your own opinion no one else will.

1 comments

I think what is hard with a lot of tech is that developers are often not plumbers. We are not encountering similar sets of problems nor are able to use similar solutions or even refer to familiar tooling all of the time. It's more akin to when the plumber crawls below your house with nothing more than a flashlight, then recoils in horror that your sewer is plumbed in 200 year old rotten wood pipe, then they start digging and hit more pipes that aren't on any map and shouldn't be there, then things get expensive and timelines enter the unknown as the problem gets seemingly bigger the more of it that you solve. Of course the client never sees this, they think you just twist a wrench, so we have these deadlines and talented people burning out over the stress they cause them.
> We are not encountering similar sets of problems nor are able to use similar solutions or even refer to familiar tooling all of the time.

Frankly, yes we are. There’s only so many ways to solve a problem and there’s only so many problems to solve in a particular field.

A senior engineer should have had enough experience to at least have a high level understanding of what is going on, and to correlate that experience with approximate work. If that’s not possible, the work is just not scoped down enough.

A team of engineers, given their combined experience and business knowledge should pretty easily come up with a story point estimate based on existing completed work. And that’s the entire point of the refinement and estimation process: getting enough information about a piece of work, then working together to come to a decision on an estimate.

Will that be right all the time? No. But that doesn’t mean the value is useless, it provides plenty of information on if a piece of work is small, medium or large, as well as if it’s expected to take a few hours, days or weeks. And who better to come up with that number than the people actually working on the issues?