That assumes that software development is infinitely scalable. If you knew going into it that you couldn't make the first deadline, just start off with more programmers, right? Just like 9 women working together can produce one baby in one month, right?
Provided you have the right software developers, the product takes as much time as it takes. Managers can't "speed it up" however much they hope, pray, and wring their hands.
"Finished in time" - if the requested product can't fit in that time window, then the only thing to do is cut features. Agile teaches us that if we start with the highest value features first, we can meet any deadline by cutting features as we get there.
Throwing intense estimation to see if you can hit that "finished in time" point with a giant list of features is simply waterfall - and studies have shown that (for most software projects) waterfall cannot predict a priori whether or not you will hit a deadline.
Thus, if you're working on a project where TIME and SCOPE are fixed, you're boned to begin with. Spending a few weeks waterfalling won't get you out of it. If anything, you burned precious developer time in the process.
No, software is not infinitely scalable, and adding a new developer won't immediately increase productivity. The general solution to concerns about delivering in time is to scale back the scope of the project. Doing so at the beginning rather than at the end helps morale, coordination with partners, and decreases stress.
Time is generally fixed to some extent. (I've never worked on a project where delivering significantly late didn't have economical disincentives. Even if Project A is worth 20 million now or 20 million six months late, money is always more valuable now than later.) Scope rarely is fixed. However, having a defined scope allows other partners to do cool things on the assumption that a given feature will be developed.
Managers can do some things that impact development time and project success. Simply knowing which features will provide the most value is a difficult problem in itself- and if team A and B don't agree, can lead to issues. Organizing a project's development time to work around code dependencies is also non-trivial with a large number of people working on a large code base.
Agile is great for small projects without large amounts of cooperation with other development teams or companies. The more people involved, and the more different groups you need to coordinate with, the value of planning, estimating, and not constantly changing requirements increases.
That assumes that software development is infinitely scalable.
I don't see how overgryphon's post assumes that; whether the project can meet the required deadlines could be a go/no-go decision rather than an assign-more-resources decision.
But even assuming you do Waterfall - which has super strict requirements gathering and estimation - you still don't get a very high degree of confidence that you'll hit some arbitrary date in the future. Again, if your software has a go/no-go based on hitting some date many months in the future, you're in a no-win situation. Odds are astronomically small you'll hit it if SCOPE, TIME, and EFFORT (people, since adding people to a late) are fixed.
Again, to paraphrase DeMarco, if the project is that sensitive to time/cost, it's probably not delivering enough value.
I've never worked in the games industry, but it's my understanding (from the sidelines, reading about EA Spouse and all that) that games company execs decide on a release date and then throw everything they've got at it to make it happen (long work hours, working weekends, etc.).
And given how often games get delayed (Unreal, Team Fortress, Duke Nukem etc.) it seems they're not very good at predicting software delivery dates either.
I'm not stating that software developers shouldn't estimate at all - sometimes considering the angles helps you design it better - just that estimation in pursuit of nailing down a delivery date weeks/months in advance is a bad idea.
We all know the quote that adding extra developers to a late project make it even later. So if you have a market-imposed deadline you've got to get the number of developers correct from the beginning of the project. Hard to do without that much estimation.
Provided you have the right software developers, the product takes as much time as it takes. Managers can't "speed it up" however much they hope, pray, and wring their hands.
"Finished in time" - if the requested product can't fit in that time window, then the only thing to do is cut features. Agile teaches us that if we start with the highest value features first, we can meet any deadline by cutting features as we get there.
Throwing intense estimation to see if you can hit that "finished in time" point with a giant list of features is simply waterfall - and studies have shown that (for most software projects) waterfall cannot predict a priori whether or not you will hit a deadline.
Thus, if you're working on a project where TIME and SCOPE are fixed, you're boned to begin with. Spending a few weeks waterfalling won't get you out of it. If anything, you burned precious developer time in the process.