Hacker News Reader

Comment by alkonaut | Hacker News Reader

This is why it’s a good idea to have ranged estimates. If a simple known thing with zero unknowns has maybe a 200% margin (1-3 days) then a more unknown task can have 10x as wide margin like 1 to 20 days.

As a developer I never get “that’s a useless estimate we can’t prioritize based on that/tell the customer that”. It’s a perfectly good estimate. It tells everyone there is a lot of uncertainty. The low lower bound indicates there is a chance it might turn out to be cheap (so maybe worth taking a gamble and trying it and giving up). The big variance indicates it could/should be given some time to prep/investigate in order to narrow the estimate.

When there are unknowns, make a wide estimate. Convey the uncertainty. If the unknowns are ridiculous, make a ridiculous estimate. Even “5-200 days” is useful because something else with less uncertainty can be chosen instead.

View on HN

I agree with this sentiment.

I'm running through a similar situation now, where I'm somewhat adjacent to a client and a dev team. The client has a list of tasks he wants done, and he'd like banded estimates for the effort the dev team thinks it will take to complete each.

The developers are obliging, but one of them complained to me privately "why doesn't he just give us 2 months of budget and we'll get through as much as we can?" - which is an interesting statement. From the developer's perspective, this is ideal. They are very good and work hard and have integrity, so I'm sure something like that would work, from their perspective. They can just 'go' and get stuff done.

From the client's perspective though, it just raises a bunch of uncertainty. He wants to know what he could get out of his 2 months of development budget. If one task took all 2 months, and the others (15 in this case) didn't get done, is that OK? What if some important task wasn't that much effort? You'd potentially want to priortise that over a bigger item.

Just saying 'give us two months of budget' doesn't take the other party into account, and what they're trying to balance or plan for. I've sat on both sides of the table, and honestly just asking for a budget with no actual commitment to completion feels selfish in my opinion. Discounting their opinion because they're 'business' people and not developers, or treating them like an enemy to fight against won't win you any friends or long term relationships.

> Just saying 'give us two months of budget' doesn't take the other party into account, and what they're trying to balance or plan for. I've sat on both sides of the table, and honestly just asking for a budget with no actual commitment to completion feels selfish in my opinion. Discounting their opinion because they're 'business' people and not developers, or treating them like an enemy to fight against won't win you any friends or long term relationships.

The irony is that at least some of the time, a "safe" estimate will actually make the project take longer. Work naturally expands to fill a deadline, and not having a deadline but instead frequent progress checkins with an expectation of foward progress can result in more getting done, because it changes the conversation from "how at risk is the deadline" to "how much happened in the last week and what are the next steps", forcing progress to happen continuously rather than one big bang at the end.

I also often hesitate to give estimates / establish deadlines because it tends to create an unhealthy confrontational atmoshepere, where developers are incentivized to not incorporate feedback or make any changes even if they are the right thing to do, because it would put the deadline at risk (but if they incorprate allowances for these things during estimation it's considered sandbagging).

> a "safe" estimate will actually make the project take longer

That’s probably the most important thing I’ve taken away from software project management techniques - everything they do is hurting them, not me. If somebody insists on shooting themselves in the foot, and they’ll shoot you if you try to stop them, you just sit back and let them shoot themselves in the foot and shrug your shoulders when it happens.

It’s easy for this honest mentality to turn into malicious compliance. If you’re actively fulfilling that prophecy, this won’t just impact a manager or a PM, it will absolutely impact you as well. I’ve seen it happen many times, obviously this goes beyond just being wrong or missing deadlines but eventually it will come back around to bite you.

At the end of the day, these estimates are helpful but maybe not in ways that are intuitive from a developer’s perspective. They’re useful in weighing priorities, judging the uncertainty, and identifying where to fill the gaps in understanding, time-boxing research and scope (e.g. do we really need to spend 6 weeks reading release notes?), and help communicate to outside stakeholders. We see the successes of this all the time with big game releases, product launches, movie releases, etc. It’s a high level measurement of progression and devs need to be a part of that planning process. It gets easier for senior engineers to do this efficiently with experience. It’s not necessarily an exercise that a more junior engineer will a) get right consistently or b) think is valuable at all.

In my experience there's two main reasons that orgs outside engineering / product want estimates:

1. Coordination of external dependencies. Stuff like product marketing, sales training, documentation, etc. as well as sometimes things external to the company like customer commitments or sales commitments. These are for the most part legitimate, although in many cases the deadline doesn't need to be known at the outset of development, and too many of these is a very unhealthy sign.

2. Accountability / improved productivity - This usually manifests as an exec feeling that engineering is running too slowly / inefficiently, and by asking for deadlines (and often compressing them to "push" the team) they can improve productivity. These are almost always in my mind completely counterproductive, and there's much better ways to accomplish this.

> From the client's perspective though, it just raises a bunch of uncertainty.

It may feel good to have some of the times quantified. But... If your estimates are literally fiction. It won't stop being fiction in front of the client. You should really spend that energy that went into the estimate for something useful instead.

Not to say you can't derive some useful information from a short planning session. Just don't expect anything other than thumb to the wind guesses.

> When there are unknowns, make a wide estimate. Convey the uncertainty. If the unknowns are ridiculous, make a ridiculous estimate. Even “5-200 days” is useful because something else with less uncertainty can be chosen instead.

As a PM, I couldn't possibly agree more with this. When you give me 5-200 days instead of "we can't estimate this", you've started the beginning of a productive conversation. I can ask you questions about why the range is so big, and you can explain to me what steps we can take (research, narrowing scope, etc.), to reduce the range.

I’ve tried this. Inevitably the response is: “We need to book UAT testers for a specific date.”

Ordinary LoB staff apparently are superstars that have their schedules locked in months into the future, but consultant SREs costing thousands a day can have their time wasted on a daily basis trying to determine how long it will take to complete a task that hasn’t even started yet.

This has literally been my last two months. The dev team lead is asking me — an outsider — how long it’ll take his team to finish something. Not because I know better, but because he doesn’t know either and prefers to make it my fault because I’m expendable.

Well, analysing the situation that seems like quite an easy one to negotiate through:

1. Talk to the person who'll get angry at you when the UAT testers are brought in at the wrong time.

2. Make it clear to them, with a paper trail, that this is an impossible task and you can either book in a best-estimate with the likely outcome that the UAT testers will arrive and there will be nothing to test OR that you can book conservatively and there is a risk the project will be delayed waiting for UAT. They can pick which risk they want to bear.

3. Put in formal feedback, as loudly as possible, that booking in UAT for a specific time introduces obvious risks and someone needs to optimise the process to be more flexible otherwise it will delay projects & waste the businesses' money.

Deadlines are a reality in all businesses (Real deadlines or made up ones). But if you have a thing to create that takes 5-200 days what will you do?

You can pull a different estimate of 20-40 out of your behind when pressured to narrow it, and make the deadline 40 days. That might be a 50/50 hit/miss the deadline, with a worse case of running over to the full 200 day worse case (or even worse - even the 200 was a guesstimate). In some cases that's fine too. The decisionmaker might just want a date with 50% chance of hitting because it's better to land a sale and apologize for the delay, than to not land the sale and go bankrupt.

The correct course of action though is to not set the deadline in that meeting. The 5-200 day estimate is a way of explaining "Either don't take this on at all, or at least don't try to schedule anything urgent based on it".

In that case as a developer I'd suggest "Let me look at this for one afternoon, and I can return with an estimate that's 1/10th as large. Then let's meet again ad prioritize some work, schedule UAT and so on". PM's often look really surprised when they realize that all it takes might be to check if there is a functionality available already or if it needs to be implemented - which represented the difference between 5days and 200. If I go off and find it's already there, the estimate is 5-10, if I go off and find there is nothing and it has to be built from scratch, it's 150-200. But without that knowledge: 5-200.

Or, if a 20-200 day estimate is actually due to real implementation uncertainty, I'd suggest "This is potentially large and uncertain. Let's try to break this apart if necessary into something that has a 10-20 day estimate and some parts that have a longer horizon. Schedule the delivery/UAT of the first functionality in 20 days, and we'll by then have a good estimate of when the remaining work will be done".

If someone in my organization would try to convince me to pull a stupid estimate out of thin air, then pressure me to haircut that estimate, then schedule something based on it (such as a delivery), then pressure me to work overtime to meet it, then one of us would be leaving the org very soon.

An interesting swap would be to get them to give an estimate for when they'd be ready for UAT, and then you take on booking the UAT.

If you're the user or representing the user, shouldn't you be doing the UAT?

Aren't we "agile" now? No UAT testers should be stuck for longer than a sprint's worth so just work it out closer to the date?

> what steps we can take (research, narrowing scope, etc.), to reduce the range

I quite literally quit my last job in February because of this shit[0]. Stop. No. These are not useful things for developers, much less senior developers, to spend their time on. 95% of my job ended up being coming up with estimates. My top deliverable to my management chain was estimates. They would only care about the actual development work insofar as it validated or invalidated the estimates deliverables.

Hard facts: If time is such an unimportant resource that you're willing to waste most of it doing "research" and worrying about scope, then you don't actually need an estimate. For reporting purposes, just BS one yourself, that's literally your job as a PM.

[0] It was well-paying, I was basically fucking around every week doing whatever I wanted, yet this issue alone outweighed all of that and was enough to make me quit.

The SO question addresses this, though: after giving an estimate with a range, the developer is pressured to narrow that range, mainly by pulling in the farther-out date in the range, and then the developer is blamed when the project inevitably comes in late because of that.

Maybe the solution here is "stick to your guns", but that can have negative career implications.

That’s perfectly expected. But the key is: narrowing the estimate isn’t free.

You can’t pull a different estimate out of thin air. And zero people will expect it.

The developer needs to say “I can say 10-100 days right now in this meeting, but given just 1 day of investigating, I’ll narrow the estimate range by an order of magnitude”.

I'm fairly certain that you aren't accounting for uncertainty properly, especially with long-tail events. Let's say you have a ticket to enable a config flag. That's low risk and relatively small. There's still a risk that there's the flag hits a silicon bug. Does your estimate reflect that risk and is it useful if 95% of tasks don't hit those issues? Consider also that estimates delivered by contractors or even other teammates will not reflect these risks and thus you look correspondingly pessimistic or even lazy.

For context, my team is in exactly this situation with several silicon bugs we found last month.

Assuming you’re pretty close to the hardware? As a standard backend web service dev os/library/device bugs are incredibly unlikely and usually defective application software is to blame. Not saying it doesn’t happen, but I can’t recall in recent memory this sort of thing happening as high up in the stack I work.

That's just the sort of stuff I see, but long tail issues that take weeks or months to diagnose can happen anywhere in the stack. Sometimes it's a hardware issue, sometimes it's a compiler bug, sometimes a VM bug, a missing browser feature, etc. Any of that can crop up even with "trivial" changes. I'd argue that it's not useful to include that in your estimates, but they're nevertheless possible and need to be incorporated in scheduling.

May I ask how you identified them as silicon bugs? And by silicon bugs do you mean random bit flips, or something else?

I probably should have said hardware bugs, as only one is in an IC (specifically an IP block). It manifests as small (but out of spec) timing errors across a network. The rest are things like improper layout, faulty components, wrong value passives, etc.

Yes - it's better to be accurate than precise. If you said "1 to 20 days" and it took 15, you were accurate. Being too precise gives you no space for the unknowns to show themselves.

Reply on news.ycombinator.com