Hacker News Reader

Comment by dhasso | Hacker News Reader

I'm always very confused about this kind of statement: "Don’t estimate". To me, projects without estimates tend to take way too much time. It's also federating a team to have deadlines. But I agree that estimations often become a joke when your manager asks you to estimate something that you have no idea how long it will take. How to reconcile both? Being more flexible on the estimation? Taking them as a team goal and not a business one? How to manage the lack of estimation when company planning is important? I can hardly see how "Ok everybody, we are going to release a product but we don't know when! Soon!" could work.

View on HN

Estimating is a bit of a joke though. It's dependent on too many unknowns. Example: How long will it take you to get to China? It entirely depends on how you're getting there and where you're coming from. I can give you an estimate, but if the only known is that you're starting in North America, and you're going to be held to your estimate, you'd better give the estimated time it'll take to walk there. The real issue isn't the estimating, it's that once you give an estimate, you're held to it even if everything around it changes.

Then use ranges instead, problem solved

I can get to China in the range of 12h and 6 Months, not including hoops to get a visa. Happy?

Yes. This is a good indication that the problem is not well understood and needs further analysis.

I've been asked to provide estimates on something in hours, and it had no requirements. They'd use this for planning purposes. It's a waste of time.

That sounds like the estimation process was screwed up, not that all estimation is a waste of time

Estimations only has value if you're not going to be held to it, otherwise people start fudging numbers. As a rough guide it can be useful, but too often it's used for more than that.

Perhaps it could be expanded upon with: Don't estimate, solve the problem.

Solving the problem may involve estimating, but blindly being asked "How long will this take?" without exploring the entire solution space, often without even being aware of what problem needs to be solved with that information, is when you get failed results. A time estimate may not even be the right tool to solve the particular problem.

If you are the one asking "How long will this take?" you have already recognized that you don't have a satisfactory solution yourself and need to defer to the experts, so why obscure useful context from those you are deferring to? While there may be some sense of pride in being the one to come up with the solution, such emotions aren't suitable for the workplace. It's okay to give someone else the 'glory' if they have the solution and you don't.

I've found estimations helpful when it's really about breaking down parts of a task that aren't independently deliverable, but still independently estimatable. When working with a sufficiently technical manager, it gives them the best idea of your confidence function. It also helps junior members of the team understand more of your process and get some problem-solving practice without years of experience.

estimate both a time and a confidence (or fitness).

2 weeks with 9/10 fitness is a very different estimate from 2 weeks and a 6/10 fitness. The latter should result in more discussion so those you're giving the estimate to can better understand how likely you are to miss that estimate and what they can do to facilitate a better estimate. "Give me 2 days to investigate this 1 thing that's a total unknown, I can probably give you a better estimate afterwards".

The problem is very few people on either side of that table ever want to do this.

Reply on news.ycombinator.com