Hacker News Reader

Comment by vsareto | Hacker News Reader

I don't doubt that estimations are useful, but you don't necessarily need to provide an estimation. Why not just say, "I'll need to look into the impact of that change and I can get back to you". What are you gaining by introducing an opportunity for your head math to be wrong? You can still keep the conversation velocity by committing to providing an estimate later, especially a more accurate one. You might be making a careless error because you're doing the math during a meeting.

View on HN

> Why not just say, "I'll need to look into the impact of that change and I can get back to you".

When you say that, do you then end the conversation about the change. Or do you keep on taking about the specifics of the change. If you keep on talking, and the change turns out to be infeasible, then you just wasted a bunch of time. However, if you stop talking and the change turns out to be feasible, you just wasted time that you and the other person had set aside.

That is good in theory but most people will have forgotten most of the conversation by the time you get back to them with your calculated values. People don't care that much about what others do, in order to grab their attention you need to be well prepared and answer things quickly or you lose them.

It's not quite that binary. There are times where your approach is the best one, likely more times than not. But there are also situations in which it'd be advantageous to provide some concrete figure/estimate in the moment, even if its not completely accurate.

> You can still keep the conversation velocity by committing to providing an estimate later,

conversation velocity, yes, but not project velocity, which is much more important.

I find it infuriating when people can’t come up with a ballpark number. You can and should check the numbers later but don’t stop a discussion.

A lot of people have the unfortunate experience of being pressed for estimates and guesses only to be held to them as though they were 100% certain, and possibly punished for being wrong.

I think a "ballpark estimate" here means "between one hour and one month", not "between two and four days". That's more like second base than the ballpark.

Ballpark estimates for software tasks are useful in situations like https://xkcd.com/1425/: before ImageNet, determining whether a photo contained a bird really would have been a multi-year research project with uncertain success, while determining if EXIF places a photo within a national park was a relatively simple GIS query. But this is not obvious to muggle stakeholders.

Of course, for things like bug fixes, scientific discoveries, and market research, often even estimation of that level of precision is unavailable. It's true that that can be infuriating, but that's just the way it is. Will this new model sell to a thousand customers or a billion? You can't tell in advance. Will this bug take five minutes or five months of effort to fix? You can't tell until you find the cause. When will we discover the next new class of antibiotics? It may already have happened or it may take a century.

“Will this new model sell to a thousand customers or a billion? You can't tell in advance.”

Very often you can know if it has a chance to be in the thousands or billions just by looking at the market size. Or you can estimate a possible size of installed base by looking at how many companies may be using your stuff.

Yeah, you can always put an upper bound on it. But that upper bound may be a billion, or a hundred billion, if you're launching a new cigarette.

I have tried asking questions that are very clearly not ammunition for later gotchas ("Can you tell me about how many digits you think the number has?") but people associate numbers with precision and remain deeply hesitant even when I explain that their wild educated guess is probably better than my wild uneducated guess.

I'd rather delay for an estimate than give something I'm not confident in. I'm most confident in estimations I've had time to think over, instead of trying to ballpark something. If I can ballpark something, it's usually because I happen to have done it before or it's an otherwise easy problem.

I don't know why one is considered a superpower over the other though (superpower is often a code word for "skills I wish everyone had because I have them"). When your loose estimations propagate to others, there's always a chance of it being taken out of context too.

If it's only you and a single person as your client in the conversation, usually things won't be taken out of context. If it's a larger org, it might become more than just an estimate.

This might even be framed as optimistic estimates vs. pessimistic estimates. One is faster but more error-prone, the other slower but more accurate. Different tools for different situations.

“the other slower but more accurate”

I am not so sure about that. From my experience quick guesses are often as good as detailed estimates that are based on assumptions that will change.

Reply on news.ycombinator.com