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.

What would you say to a games company that wants to get their triple-A title out in time for the holiday season, instead of releasing it in January?

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.