Every software developer has heard about the Gang of Four and their classic Design Patterns book. It’s really a must read for any serious OO developer. Awareness of (and more importantly the judicious use of) design patterns is rapidly becoming a prerequisite for writing code in the first place, like breathing or a high tolerance for caffeine.
However, I personally believe that over-reliance on design patterns leads to bad Agile practice. Let me give you an example. There’s a pattern called Dependency Injection, aka Inversion of Control, which decouples a client from the implementation of a helper class. Martin Fowler covers this in mind-numbing detail here, along with a related concept called a Service Locator. The main problem, from an Agile point of view? When you really get down to it, it just moves the dependencies one (or more) levels away from the class in question. You still have to have that information somewhere.
Dependency injection is an easy concept which rapidly gets out of hand in the endless “what-if” brainstorming that happens from time to time when a few smart and excited software geeks get together. You’ve heard it before: “Let’s just encapsulate this code in an abstract base class that inherits the ILookup interface…”
One should assume that this is a prima facie violation of YAGNI unless there’s a clear customer requirement that couldn’t be met in a more direct way. Extending a bit, most of the patterns that add complexity at the expense of understanding should probably pass the YAGNI test before you jump ahead with them.
You may ask, “Doesn’t this lead inevitably to sloppy / spaghetti / cowboy / repetitive code?” Remember, Agile is not about No Design, it’s about Just Enough Design. And testing. And doing what the customer wants, not what you think they will need X years from now. And iteration. And lots of other practices, most of which tie together to help the entire concept work.