4 ms·

I've spent my career living in sales and engineering camps. I've managed whole sales organizations and written full applications from the ground up. I could not

I've spent my career living in sales and engineering camps. I've managed whole sales organizations and written full applications from the ground up. I could not disagree more with the author that time estimates should be eliminated. The business does not exist without revenue, and revenue is less likely to be retained (customers) or acquired (new customers) when the business is unable to anticipate product delivery timelines. Think about all of the other business functions that key their todos and deadlines off of a product release. There is also the question of accountability. I'm intrinsically motivated to be productive, but even I value knowing if I am tracking well on a burn down chart. It gives me daily insight into whether or not I should communicate a need to trim scope or coordinate a deadline change with the other business functions if scope can't be trimmed. Kanban is awesome for bug fixes that are hard to anticipate, but any dev worth their salt should be able to offer a time estimate. If something happens, then communicate why the estimate has to change and keep incorporating the lessons learned from into future estimates.

hdhzy 9y ago
I think developers are kind of afraid to estimate, especially when these estimates are treated as commitments and not... well, estimates. Evidence based scheduling [0] is an interesting approach to scheduling that may ease some of these pains but is not without drawbacks (e.g. estimation itself can take a lot of time). [0]: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
- djklanac 9y ago
  This is awesome. Thanks for sharing this.
einrealist 9y ago
I am "worth my salt". I think so. But when I was asked for estimates, I told them a number, but only after I told them that that number is without foundation. It is an estimate, a guess. At many clients / projects, it was taken as a guaranteed time, a deadline - despite my effort to explain that it is just a guess. And when things got bad, it was often used for blame. Because of this experience, since 2-3 years, I am fighting estimates unless I am in an environment where estimates are really only estimates.

hdhzy 9y ago

I think developers are kind of afraid to estimate, especially when these estimates are treated as commitments and not... well, estimates. Evidence based scheduling [0] is an interesting approach to scheduling that may ease some of these pains but is not without drawbacks (e.g. estimation itself can take a lot of time). [0]: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

djklanac 9y ago
This is awesome. Thanks for sharing this.

einrealist 9y ago

I am "worth my salt". I think so. But when I was asked for estimates, I told them a number, but only after I told them that that number is without foundation. It is an estimate, a guess. At many clients / projects, it was taken as a guaranteed time, a deadline - despite my effort to explain that it is just a guess. And when things got bad, it was often used for blame. Because of this experience, since 2-3 years, I am fighting estimates unless I am in an environment where estimates are really only estimates.