[jacques_chester]

I see a lot of cases of people saying estimation is impossible, which upon closer inspection turn out to be a different argument: "perfect foresight is impossible".

The Nirvana Fallacy, in other words. Because it's not perfect, it's worthless.

Of course perfect estimates are impossible. You need to make them anyhow. And if you don't make them explicitly, you'll make them implicitly, and they'll be worse.

[x5n1]

That's not the problem. The problem is that each step in the process is variable, and it's not variable by a small amount but potentially up to a magnitude. That's the problem. The second problem is that the industry does not pay for reasonable estimates, they want imperfect unreasonable estimates which are very conservative with which to beat the employee or the contractor over the head with to force overtime and crunch.

[jacques_chester]

> The problem is that each step in the process is variable, and it's not variable by a small amount but potentially up to a magnitude. That's the problem.

That's not unique to game development. Or software. Or any industry, really.

> The second problem is that the industry does not pay for reasonable estimates, they want imperfect unreasonable estimates which are very conservative with which to beat the employee or the contractor over the head with to force overtime and crunch.

Of course, but that's because the estimate is not being treated as an estimate. It's being treated as a plan, or a goal.

I read a book called Industrial Megaprojects in which the author, talking about civil and industrial projects on a gigabuck scale, lamented the same problems.

[marcosdumay]

> That's not unique to game development. Or software. Or any industry, really.

Yes, it is. It's not literally unique to software, because R&D and "nobody ever made something like this" projects share it, but most industries don't.

[Macsenour]

In games we HAVE to push things forward, we HAVE to innovate or seen as a copy of an existing product. That being said, that's what "Pre-Production" is all about, answering the questions that are new to this project.

In the piece it says something about "needing more windows", that isn't what I'm talking about. That's just poor game design at the outset.

I was refused an interview once because they were looking for the exact person who had done a hit title, he "obviously knows what he's doing". The product in question was 2 years late and 1.4 million over budget. I said: "I can do that...". I think the game industry is unique in that we're often hired, or not hired, based on how famous the title was that we worked on last.

[nradov]

The US Navy developed evaluation and review technique specifically to solve the first problem. For a particular task you can say: optimistic time = 1 week, most likely time = 2 weeks, pessimistic time = 20 weeks. If you decompose a large project into a large number of smaller tasks then the critical path schedule estimate should be close to reality. Or if you want to be more sophisticated you can do a Monte Carlo analysis to create a probability distribution of possible completion dates, and then make commitments based on whatever statistical level of confidence makes you comfortable.