The perils of "There's more than one way to do it"
At the very beginning of my full time programmer career, when I worked at Silicon Graphics, Larry Wall and Randal Schwartz gave a brown bag session about their now legendary camel book. Naturally, I had them sign my copy, the front page of which I proudly display at left. Notice the “There’s More Than One Way To Do It!” stamp at the top. For better or worse, Perl is famous for this property. Less famous (or perhaps even infamous) for having more than one way to do it is JSF.
At the JSFdays conference last week, I was having lunch with a friend who is an experienced developer and the topic turned to JSF deployments in large projects. He mentioned that his project was bitten by the fact that there was more than one way to do it in JSF. If you give developers more than one way to do something, they'll take advantage of that capability. But, in a large project with many developers, this can lead to confusion and unmaintainability.
The simplest remedy is to establish firm and strong conventions for how to do things for which there is more than one way to do it. Of course, this is easier said than done, but I believe, as do Wall and Schwartz, that having more than one way to do it is generally an asset rather than a liability.