But sometimes you need to know what is you are designing before giving it to people, because there are large risks associated with improvising. In those cases, making The Right Thing is still expensive, but it may reduce the risk of catastrophe.
I think, however, that the latter cases are rarer than most people think. There are ways of safely experimenting even in high-risk domains, and I believe doing so ultimately lowers the risk even more than doing The Right Thing from the start. Because even if we think we can spend years nailing the requirements for something down, there are always things we didn't think of but which operational experience can tell us quickly.
Same author (name is an anagram).
Also: Nickieben Bourbaki might be an anagram of something, but it is definitely not an anagram of Richard Gabriel, with or without the P. There's no G, there's no h, there's an N and a k, it isn't even particularly close.
That claim is my best interpretation of this sentence:
> Same author (name is an anagram).
Although perhaps it was not your intention to connect the clauses in that way.
The time to market for the MIT approach is just too long if your revenue relies on actually shipping a product that covers the cost of the next iteration that will move you from 80% to 90%, or even 60% to 70%. It's an old joke, but in the long run we're all dead; and waiting for the production of an ivory tower implementation won't work out well. If it's all academic, and there's no commercial pressure, well, have at it. There's not much at stake except reputations.
Furthermore, in the real world, your users' requirements and your internal goals, theoretically covered by "the" design, will change. Not everything can be reasonably anticipated. The original design is now deficient, and its implementation, which is taking too long anyway, will be a perfect reflection of its deficiency; and, not fit for its new purpose.
Get something out there and start getting feedback. You won't actually know until you do.
Often in these arguments, worse means "shortcut" and better means "won". The difficulty is proving that not taking the shortcut had some other advantages that are assumed, like in the article.
This "victory" is fleeting. When people people tell you C++, a language which didn't even exist when I was born, is "forever" they are merely betraying the same lack of perspective as when Britain thought its Empire would last forever.
Still I am a bit bothered, does a counterargument exist?