zlacker

Software estimates for projects that don't involve significant technical risk can be made reliable, with sufficient discipline. Not all teams have that level of discipline but I've seen existence proofs of it working well and consistently.

If you can't make firm delivery commitments to customers then they'll find someone who can. Losing customers, or not signing them in the first place, is the most harmful thing to everyone in the organization. Some engineers are oddly reluctant to accept that reality.

>>nradov+(OP)
That assumes you’re working in some kind of agency or consulting environment where you repeatedly produce similar or even distinct things. As opposed to a product company that has already produced and is humming along, which is when most people get hired.

Estimating the delivery of a product whose absence means zero product for the customer is very different. A company that’s already humming along can be slow on a feature and customers wouldn’t even know. A company that’s not already humming is still trying to persuade customers that they deserve to not die.

>>threat+s2
Not at all. This can work fine in product development, as long as you limit the level of technical risk. On the other hand, if you're doing something really novel and aren't certain that it can work at all then making estimates is pointless. You have to treat it like a research program with periodic checkpoints to decide whether to continue / stop / pivot.

>>nradov+(OP)
> If you can't make firm delivery commitments to customers then they'll find someone who can.

Rather: the customer will find someone who can confidently pretend that thet can make firm delivery commitments.