Firstly, the business might not realize that the original path that they decided one wasn't the correct one to begin with before looking at the finished iteration. So even though there are a huge part of the codebase/effort that goes to waste, it can be considered worthwhile. Without it, the business might not have known the right path. It re-emphasize the point about continous improvement.

The best practise+unit test is an insurance, to ensure if the business got it right, you can proceed further with confidence. Agile is about maintaining consistent sustainable speed, not getting somewhere fast.

Secondly, what you're describing as do it fast and pay the debt later is spiking/prototyping, and there are times to do that. But the goal has to be to work out what to put in the backlog, as oppose to getting version 1 done.

There is obviously alot of caveats, and the points I've given above mostly comes from theory. WOuld love to hear if it's applicable in practice. thoughts?

But, what I want to say here:
What if the business doesn't even know the direction or what they want. Like in my example, the business wanted to build a product. We'd spent amount of time on analysis and then development. Daily standups and regular updates on the project to make sure we are on right direction.
However, in the middle of the project, all of sudden, they asked us to stop the development. They said they wanted to change the direction and the features we were developed were no longer giving any values to them. So they wanted to drop many features and replace it with new ones.

What can you do? No matter how good the code you wrote, you have to give it up. Right?

My point is: in this kind of environment, I would rather to build something quick and pay the debt later. So, instead of spending time on TDD, thinking about the best architecture, what design pattern to use, and etc, I would pay more attention on product delivery.

Don't get me wrong, build quick, doesn't mean I give up some of the rule of thumbs on software development. But, i would rather to go for the not-too-so–the-best architecture. But it allow me to release code more often and faster.

Ron, I can feel that, you'll disagree :p
Correct me if I'm wrong…

PS: After I read the blog again, seems my first comment isnt appropriate to the context.

I would question a couple of things:
1. daily standups should've caught business changes early.
2. if not, are you sure the right people were in the standups, and proactively engage with the development
3. is the codebase, modularized and easily tested as a small unit?
if it is, you should be able to take advantage of the open close principle. Leave the code base intact, create a new small class that does the new requirement, configure your IoC container to use the new class.

Any practice will be 'over-engineering' without the proper context.

Thoughts?

Once upon a time, I wrote software from the scratch in TDD way. It was awesome, I'm so proud that the code is highly testable with high code coverage, but unfortunately business changed their mind in the implementation and require almost 70% code to be changed. Very sad indeed. But I learnt something. TDD is not agile..

That's why I tend to agree with what you say above man.. regular release and continues improvement are far more important.

Btw, have you read Joel's Duct Tape Programmer article, in some way im agree on his view which I reckon is more suitable to agile.

Anyway, Just my 2 cent..