[BlargMcLarg]

That's not an excuse when the same thing happens the other way around:

"Let's have discussions until 2 weeks before the deadline for something that needs 2 weeks of development time!"

"..wait, why are we having performance issues? Why did we not think of this one case that's occurring every 5 seconds?"

People are very eager to take article's example and use it to slam individuals they have a vendetta against, while looking away from the other extreme which has the exact same problem. Going too fast is a problem. So is going too slow and LARPing as a clairvoyant, getting close to a deadline and then business forces you to get disciplined and deliver something not battle-tested.

[k__]

Guess that's an experience problem.

The more right on the curve you are, the higher the chances that you met people that decided too fast than too slow.

But yeah, your probably right.

[mewpmewp2]

The more experience I have had the more it seems like people won't know ahead of time what has to be done. So if there's a lot of planning involved without getting the thing to customers, there's whole a lot of speculation where 90% of the planning gets completely turned on its head anyway, when finally actual customers are able to use the thing.

And then slow builds and decisions would have to be rewritten anyway. Usually with many assumptions baked in.

So I highly prefer fast iteration where you get at least something out for the customers to use as soon as possible.