[tsimionescu]

Having a deadline (plane must be ready by December 1st) and missing the deadline because of quality issues (plane was not air-worthy by December 1st so we can't let it fly) are not mutually exclusive. Deadlines do not mean that quality has to be sacrificed.

Even for the most objective deadlines (contractual obligations, holiday promotions), there are alternatives to releasing a low quality product, and the pros and cons must be measured. Does paying damages for failing to live up to the contract beat the reputational (or even legal) damage of releasing a low quality product that technically meets contractual obligations? Then a responsible company will pay those damages. Does releasing the product on time for Christmas, even with the level of bugs known and/or potential unknown ones, gain you more good will than delaying it by a few weeks? Then uphold the deadline and promise a patch soon after.

[ahaproudowl]

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.

[tsimionescu]

Deadlines and delivery dates are the same concept.

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.

[hef19898]

Heck, sounds a lot like my current place! A lot of talk about "critical path", agile and sprints everywhere, even on the hardware development side, a lot or reprioritization going on. And guess what, all prmosed dates and schedules are constantly missed. Mind you, that the whole place is living of investor money and needs more that rather soon.