|
|
|
|
|
|
by ahaproudowl
1372 days ago
|
|
|
The deadline is an arbitrary guess, based on experience of when something will be ready. Of course delivery dates are important, quality is also important. The author I think could phrase the argument better by saying a delivery date (something that is promised, based on quality) is more useful than a deadline (something demanded, regardless of quality). Delivery dates do not preclude working hard and bring prudent, but they are not hard stops. Rather they are good estimations that can and often do shift. Sales team needs that thing by December 1st? Don't ask for it on November 29th. Put leeway into the model by giving time for the delivery date to be missed. It's called contingency. But, depends on your philosophy - move fast and break things,or deliver consistent quality code. |
|
|
The alternative the article proposes is entirely different - it proposes a work queue system, where the team is always working on the most important current task(s), and where every task that is taking longer than some pre-determined number of days is re-evaluated to make sure it is still as important as believed.
> Sales team needs that thing by December 1st? Don't ask for it on November 29th. Put leeway into the model by giving time for the delivery date to be missed. It's called contingency.
That's not how the article thinks. Instead, it views it as "sales team needs some task done by some date? move it to the top of the work queue as soon as you know about it and the team will finish it as fast as possible anyway". Will that be before or after December 1st? No one knows, no one cares: it will be done as soon as possible.
For inherently fixed scoped tasks (say, "our product must ask users for consent before collecting data"), this can work fairly well. But I don't think it is realistic for the vast majority of work, which is far more vague in terms of scope.