Programmers I�ve known spend too much time learning �how� or �what� and not enough time learning why.

All programmers learn the three fundamental principles of object-oriented programming: inheritance, polymorphism and encapsulation. They learn rules about these concepts, such as �when possible, favor composition over inheritance�, the DRY principle: �don�t repeat yourself�, and �be sure to decouple view logic from business logic�. Programmers (being the intelligent math-educated people they are), memorize the rules and apply them whenever possible.

Here�s the problem. Most of these rules were not meant as absolutes. These are not like the rules of physics or geometry. These are more like the rules of grammar or art: �complementary colors provide contrast�; �photographers should use the rule of thirds when composing a shot� or �don�t wear white after labor day�.

You don�t become a better craftsman by knowing more rules than everyone else. You become better at your craft by understanding the rules, why they exist and what contexts they can be applied to.

A popular buzzword I�ve heard being abused lately is �decoupling�. Unlike with marketing buzzwords, the problem doesn�t seem to rest in a misunderstanding of the original definition. Programmers just don�t stop to consider why they are �decoupling� their code. It is true that in many cases programmers tend to write highly coupled code. Many programmers don�t appreciate encapsulation nearly as much as they should (at the class level or subsystem level). This has led to some great books such as �The Pragmatic Programmer� and �Effective Java� that re-teach the basic concepts of OOP. The authors repeat the rules we read every day and explain why they are important (again).

The average programmer will read an entire chapter on decoupling code and walk away with:
Decoupling = good
Coupling = bad
We see the results of this oversimplification every day: seven levels of indirection for a single Session Bean call? A property file that tells me how to find my property files directory? A programming language written in xml?

Lets get back to the concepts. Decoupling exists to improve encapsulation. Encapsulation exists to improve maintainability. Many times externalizing logic will improve maintainability. Many times you�re just making a big mess! Decoupling code for any reason other than maintainability is a waste of time.

I love The Pragmatic Programmer series by Hunt and Thomas and many other books that teach everyday concepts that everyone should understand. I wish some of these books would not only explain the benefits of their philosophies, but how to tell if you�re taking them too far. More importantly, however, I wish programmers would read these books, absorbing the concepts rather than just the rules.