Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Even when developing your own stuff internally, you have a limited resource: your dev team's capacity to do work.

The most important question for your internal software team is still "what should we work on" and estimates are a fundamental part of answering that.

It's someone's job to figure out what things that team could do to provide the highest value. Usually some combo of product/sales/marketing/tech.

But that's only half the equation! You also want to know how much it's going to cost, in terms of those scarce dev resources. If one project would add X value but take a year, and another set of projects would add Y, Z, and A value, but each only take four months, you want to compare Y+Z+A vs X to see what gets you the most value over the next year. So the better the estimates, the more rational you can be about what work gets done. If you have no estimates, you might pick a project that will go on for way too long, and not get the value out of it that you expected.

(However, I doubt anywhere truly uses NO estimates. I've never seen a place that didn't at least have an informal level like "oh that'll be really hard" or "that'll take us a long time.")



There's a qualitative difference between the sort of informal estimates you mentioned ("it'll be hard") vs the sort talked about here—people don't treat the informal estimates as commitments!

As soon as an estimate is really a commitment it totally changes the dynamics around it and actively impacts autonomy, so my impression is that what people mean by "no estimates" is more like "no timeline commitments".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: