|
|
|
|
|
by Frost1x
1372 days ago
|
|
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. |
|