In this month’s edition of MSDN Magazine (June 2009), there is an article by Daniel Simmons titled "Anti-Patterns To Avoid in N-Tier Applications". In this article he talks about several pitfalls to avoid while designing a N-Tier app.
He touches on how simple it is to write an N-Tier program quickly. However if there are changes, you will be in trouble. He gives advice on how to avoid the problem, by using best-practices. Then, throughout the article, he leads into the next pitfall and solution, then the next. It was well-written and succinct.
My favorite part of his article was at the end, (Anti-Pattern #6) when he points-out that, simply by adding complexity, you will probably make your life worse. For example, all these best-practices, basically added complexity and, if you would have chosen a simpler approach, you would have been better-off from the beginning. This is one anti-pattern that most authors simply skip or completely overlook. I love it when an author uses the cop-out: "Of course, you should always use the right design for the right task". ..whatever that means!
I have been trying for years to convince various colleagues (that I have worked-with) of the benefits of simplicity. Many of them have stared back at me in disbelief. They have strong beliefs that brilliance is only demonstrated by embracing and increasing complexity, instead of avoiding it.
I often shake my head in disbelief when I see some of the complicated messes that people create in the name of "Object-Oriented Programming". OO was originally invented to help organize programming teams into groups or strata. So the programming teams could be managed separately and play to their strengths. It usually resulted in shifting the complexity to a more manageable area of a programming project.
However, today, most programmers work on their own and use ridiculous or outlandish object designs that only add complexity with no benefit in return. When asked why, they can only respond with "because that is the way you are supposed to do it" or "That is the way they teach it in school". If asked "is this way always the correct way" they will relent that it is not, but they cannot tell you WHEN it is not the correct approach or UNDER WHICH circumstances, a simpler approach is appropriate. The only tool they have is a hammer, so everything looks like a nail.
I was relieved and refreshed to see that this story was listed on the cover of MSDN and that Anti-pattern #6 wasn’t slashed from the story by some over-zealous geek with a bloated ego.
Hats-off to Daniel Simmons. We need more good advice like this.