Agreed - I understand the point of the article and that my post does not directly address that point. But it does challenge OP's statement (which I italicized) that he uses as a basis for his conclusions.

I fully agree that iterative analysis and development is usually quicker than the waterfall method. I'm just adding that a little thought each step of the process can make everything quicker. If you think things through enough (which more experienced people often do better), you can have your cake and eat it too.

Don't forget that some of those final t's are because you already invested a lot of other t's and d's into doing it the wrong way.

Sure, but

ttttttttttttttttttttttttttttttdddddddd

Startups have areal risk of running out of money, just before they complete enough d. However with

ttd,

I have a shot at cashflow with that d, which I can invest back into more (nt +nd)

Established companies dont have that risk so they can do

ttttttttttttttdddddddddddd

While for startups it makes sense to do

ttddttddttddttddttddttdd... etc.

For a minute there I thought you were going to do

  tddtddtdd

I'm not sure what you mean -- that if you hadn't done the first three steps, you wouldn't have needed so many t's in the last?

you already invested a lot of other t's and d's into doing it the wrong way

But the first three steps were an incredibly valuable investment -- now you know the right problem to solve!

(Maybe you mean something like this, just not sure from your comment.)

You're thinking about it from a business development standpoint in addition to a technical stand point.

I'm just talking about the technical approach. You've gained no new insight into what your business is supposed to be, you've just learned a hella wrong way of solving a technical problem. Now your thoughts are cluttered with the effort and you had to spend time unlearning the previous approach.

This is even more true if you make the d stand for debugging.