[traceroute66]

> Yes, imagine air travel wasrun like that:

Erm, except air travel DOES run like that.

Deadlines are at the very core of air travel.

The crew agree on a flight plan and file it.

If the aircraft goes AWOL and does not arrive at its plan waypoints by time + buffer, then all hell breaks loose.

There are also deadlines for landing slots, deadlines for flight closing, deadlines for this, that and everything else....

Aviation without adherence to deadlines would not work.

As for maintanance, airlines keep a ready stock of parts and have relationships with maintenance organisations at all major airports. There are also regular scheduled inspections. An aircraft on the ground is a loss making asset, it is in the airline's best interest to maintain the to flightworthy standards at all times.

[Frost1x]

Your point is very valid to the above but I'd like to fix GP's example. The distinction here is that what's being discussed is more about deadlines that are built around systems that are already deemed stable and mature, already went through all these processes and now have a fairly stable level of uncertainty and data surrounding it they can work with.

Imagine more if the airline promised a flight would be ready using a brand new plane that was just now being designed out or at some stage in development someone unknowledgable felt comfortable to start making promises about timelines and even extrapolating out production. New plane designs and manufacturering take years and years sometimes. Have all sorts of delays, have safety issues that require them to redesign things later and so on. You don't see a lot of new plane designs you see the same known things used over and over.

It's one thing to make forecasts around fairly well known, established, and mature systems and processes, it's an entirely different beast doing so around less known systems and processes. The vast majority of software engineering and development is done around something new or different that has little contextual reference. If you do have reference then you're rebuilding the same things using the same pattern and it won't be long until libraries, frameworks, systems, processes, etc. emerges to automate that at which point your time shifts to the new things you need to automate which haven't been automated or done yet (again, otherwise you'd just leverage the prior work).

Planning to make a site using something like say Django vs building a new framework with different features like Django are very very different and a lot of development is trying to do something unique and new which means high uncertainty.

[galangalalgol]

In that case deadlines are useful because you have so many people depending on you that you don't know which or how many of them have real dead lines. That isn't as common in software I think?

But needing a new working iOS by ship time for the next phone? That is a pretty hard deadline, and why apple doesn't use agile. They say agile doesn't support synchronous hardware/software releases.

The problem is when I bsupport multiple efforts, some with deadlines and aome without, the ones with deadlines always get "done in a minute" descoped so that I don't starve an ongoing que as is described here.

[chociej]

I think it's easy to argue that all those things are what the author would call preëmption points