3 ms·

Estimates are to be avoided at all cost. They create needless pressure, competition, and participate in a toxic witch-hunt of who is the less productive. In th

Estimates are to be avoided at all cost. They create needless pressure, competition, and participate in a toxic witch-hunt of who is the less productive. In the software development world, it is impossible to produce meaningful estimates, let alone precise ones, for anything but nano-tasks. Perhaps this can exist in the academic world, but once you have customers and release dates, sometimes you have to work around the date rather than the abstract. Dates also provide motivation if they're not abused.

pdimitar 10y ago
The fact that somebody imposes deadlines on you doesn't magically change the nature of programming however. I agree on the realities of the world out there -- which still don't apply to 100% of it, by the way -- but what you're saying is that we should unquestioningly accept an artificial byproduct of the business world realities imposed on our craft, or am I misunderstanding you? Communication is paramount. If there's no mutual understanding, the relationship will collapse, along with the software project.
- mathattack 10y ago
  Sometimes it can. Sometimes teams plan based on "How long does it take to implement these use cases?" Other times (more frequently in agile) it's "How many use cases can we get by date X?" It's harder to commit to the first scenario than the 2nd, since the 2nd (in practice) implies that the date transcends scope so you can take items out.
  - pdimitar 10y ago
    In my 15 years of commercial practice, I feel that your 2nd scenario very rarely translates well to reality: most of the times you need to put some foundations in the code that would allow features A, B, C, D and E. Even if your Scrum Master is liberal and tells you "OK man, we don't have much time, put features A and B only", this doesn't change the fact that often times the initial overhead of all 5 features takes the most time. Outside of that, I definitely am in agreement with you.
    - mathattack 10y ago
      I think we're on the same page. The world isn't black and white. It's a matter of accepting which constraint (scope, quality, timeline) is the dominant one.

pdimitar 10y ago

The fact that somebody imposes deadlines on you doesn't magically change the nature of programming however. I agree on the realities of the world out there -- which still don't apply to 100% of it, by the way -- but what you're saying is that we should unquestioningly accept an artificial byproduct of the business world realities imposed on our craft, or am I misunderstanding you? Communication is paramount. If there's no mutual understanding, the relationship will collapse, along with the software project.

mathattack 10y ago
Sometimes it can. Sometimes teams plan based on "How long does it take to implement these use cases?" Other times (more frequently in agile) it's "How many use cases can we get by date X?" It's harder to commit to the first scenario than the 2nd, since the 2nd (in practice) implies that the date transcends scope so you can take items out.
- pdimitar 10y ago
  In my 15 years of commercial practice, I feel that your 2nd scenario very rarely translates well to reality: most of the times you need to put some foundations in the code that would allow features A, B, C, D and E. Even if your Scrum Master is liberal and tells you "OK man, we don't have much time, put features A and B only", this doesn't change the fact that often times the initial overhead of all 5 features takes the most time. Outside of that, I definitely am in agreement with you.
  - mathattack 10y ago
    I think we're on the same page. The world isn't black and white. It's a matter of accepting which constraint (scope, quality, timeline) is the dominant one.