Michael's Pattern Laws

Here are some laws I found in the last years as a software architect I'd like to share of you. Maybe, you could share your own insights.

1. Patterns are no surrogate for human intuition and creativity.
2. Overload of patterns in your software architecture implies overload of problems in your system. However, not using patterns where applicable may make your life extremely unpleasant.
3. If you just found that cool new pattern, think again before bothering the rest of us! (Remark: I also want to remind you of Brian Foote's famous words: " a pattern is an aggressive disregard of originality").
4. Patterns are your best friends if they are treated with friendliness in your architecture design.
5. It is easy to become a pattern author but it is surprisingly hard to write a good pattern description.
6. If grandma understands it, it is propably a good pattern description.
7. Patterns that can be easily formalized are no patterns.
8. Patterns and Agility? Patterns are about agility. Without patterns your software architecture tends to become overly complex and thus hard to maintain, change, or evolve.
9. The number of pattern books has significantly increased in the last years but that is not necesssarily a sign of good quality.
10. Patterns are dead, CORBA is dead. All technologies that turn from hype to pragmatic technologies are declared dead once upon a time. If a technology is considered that way, it is typically safe and valuable to use.
11. A pattern is no island. It reveals its true power when connected with other patterns to form complete landscapes.
12. You can classify patterns in infinite ways. For example in structural, behavioral or creational patterns such as GoF. Or you may partition the pattern space with respect to granularity, process phases or domain facets. I prefer to have only two classes of patterns, good ones and bad ones.
13. Time is money. Applying patterns saves time. Thus, patterns are money! Don't forget to tell that your managers.
14. Always add a real life example to your pattern descriptions because some non-software people in your projects won't see the value of patterns otherwise. Take management as an example.
15. If you are a good guy, apply patterns. If not, anti-patterns might be a more appropriate choice.
16. Patterns are not just collections of UML diagrams. I totally agree with Bertrand Meyer who once said "bubbles don't crash" and "all you need is code". Developers should memorize those sentences.
17. Applying the right patterns the right way is like paradise. Applying the wrong patterns or applying the right patterns wrongly, however, is like hell. Thus, make sure you know what you are doing here.
18. Sure, you got all pattern books. But that doesn't make you a pattern expert automatically.
19. As the pointy-haired boss always ephasizes in Dilbert "work smarter not harder". Applying patterns is generally considered smart.
20. Beware of Murphy's Laws when applying patterns.