The duct tape programmer and the patterns geek.

Is there a middle road.

I just finished the book "Design Patterns In Action" and I am starting the "Refactoring to Patterns".

Then I find the following post by Joel Spoolsky:
http://www.joelonsoftware.com/items/2009/09/23.html

A danger of our undefined industry is addicting yourself to bits and pieces underway. You get pet peeves that are secondary to the actual business that your profession is a part of.

I am completely sold on TDD, but there certainly is a ladder for its business value with distinct stages.

If you don't have coverage or reliability on your tests, you can't refactor with a vengeance.
If you don't do tests first, you have significantly less chance of producing decoupled code.
If you can't refactor, you will still produce a mess.
If you can't refactor into patterns, you wont see the tests driving the design.

But, at the end of all this and you leverage TDD to its fullest, have you become overacademic along the way?

Does TDD, in all its glory, scale downwards?
Both with respect to project size as well as timeframe.

Are there scenarios where your excellent TDD skills scale so bad that they become an obstacle to getting things done and shipping it?

Robert Martin says "Do not go fast, go well".

My perspective is that IDEs that promote a test first discipline and powerful add-ons like Resharper or Coderush makes this discipline go faster and sturdier. Also, future architectures seem to promote logic and presentation in a more clear cut manner.

As I've stated in an earlier blog post, the jury is out and TDD won, but I appreciate the duct tape programmer perspective. Although I suspect he is a dying breed within the mainstream where people have to maintain code bases and incurred technical debt carry interests.