That's true if you are building something tangible. You can't simply start building something (like a bridge) and fix the mistakes you make while you are making them.
But for programming ? You don't have those kind of costs.
But for programming ? You don't have those kind of costs.
Where did you get this strange idea from? You have customers, backwards compatibility, programmers time, and tons of other "cost" stuff.
None of which matter. The idea being if you are working on a component for version 2.0, even with all these "costs", it's better to iterate quickly. The only thing that is close to mattering is programmers' time, but even that is addressed in the article. Simply that it's faster to fail fast and iterate until you get the correct solution than it is to spend all that time planning.
[1] http://www.infoq.com/interviews/agile-software-architecture-...
At the simplest level, 5 days of coding something that you realise doesn't do what you want is 5 days you'll never get back.
At places like mine, where you've got multiple third parties that you're interfacing with, sending them off to develop something before being 100% certain that they are doing the right thing could - and reasonably frequently does - have many thousands of pounds of cost implications, and many months of delay, when you realise that a particular call needs to real time instead of batch for example.
In product (prototype) development, there's a maxim that's followed by a lot of people "Plan to throw the first one away" or something to that effect. Sure, it may not work for every case. But, for lots of projects, it's useful to accept the notion that you will learn enough building the first one to get more value out of throwing it away than by keeping it. There are just too many things that can't be seen without a (probably) unattainable level of diligence.