A Whole Lot of Common-Sense is What It Is
Yesterday I mentioned that I had to read two books (actually the non-cataloged sections of those books) for a new client. Well, I got through that material this morning and familiarized myself with the catalog, and I thought, "this is a bunch of common sense." Now, I'm not knocking the books - the material is fine (actually, I kind of enjoyed "Refactoring to Patterns"). There's nothing wrong with refactoring, but really, it's something that every developer should be doing anyway. And patterns...ugh. Patterns are fine, but some architects overhype them as the silver bullet ("hey, let's use the Strategy pattern - that'll solve all our problems!", "Just use a Factory - that'll clear everything up!"). I'm definitely not one to "study" patterns, just because I find that time not very well-spent. I thought that way years ago - I used to buy lots of patterns books. Then I started to read some, and 4 days after the coma wore off, I realized that a much better way of learning about patterns is to actually code, and see the patterns that emerge. I don't memorize patterns in the classic GoF sense; frankly, there's not a lot I memorize anymore. Rather, I try to remember good solutions to problems and reuse them in future work.
I'm not "against" patterns or refactoring; I just think they're common, every-day things that developers should do and apply where necessary. I do get concerned when I hear managers and architects talk about making all their developers learn and study patterns. That can be a sign that they're looking to fix problems with a simple "apply patterns everywhere" approach, but some problems will not be solved by patterns. As I've said before, I have one main goal with a client: solve their problems the best way I can with the tools and time available. I'll never get the "perfect" system in place, but I'll do my best to get something done that works well and is maintaineable.
* Posted at 06.16.2006 10:51:27 AM CST | Link *