All these techniques essentially provide a systematic approach to some aspect of development. Each is presented as being a kind of universal design pattern applicable to every situation imaginable.

What you learn at some point is that working within a system, any system, is constraining. You may be trying to do functional programming, and then realize that solving your problem would be so much easier if you could use an imperative data structure, like say, a hash table? You may be doing OO, and find a solution for which it would just be simpler to use a function and a struct.

Also, every development paradigm is domain specific, which is not something they tell you when you are learning it. Look at the patterns in the GoF book. They are all centered around the kinds of desktop GUI programming that people did in the 90′s, and how to solve those problems in a particular kind of language. Some patterns, like Singleton, are now maligned as being incompatible with TDD.

Now, ask yourself this, what kind of limitations are there in unit testing? Are there some domains where unit testing really makes no sense and we’d be better off doing say, static analysis? Maybe even (ugh!) proving the correctness of algorithms? Is TDD domain specific?

Here’s a hint: check out the Linux kernel tree and try to find unit tests. Ask yourself, why aren’t they there? Is Torvalds just dumb? Then think about the implications that threading, non-determinism, and heisenbugs have for unit tests.