Skip to main content

The perils of "There's more than one way to do it"

Posted by edburns on March 3, 2010 at 1:55 PM PST

Image of signed camel book saying 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.

AttachmentSize
19951201-camel-book-signed.jpg419.54 KB

Comments

There will always be more than one way to do it

The key is to make the preferred way for the majority of cases also be the most obvious way... to both the author and the reader.

Be flexible, or die!

Having "more that one way to do it" gives the system an inherent advantage, perhaps one of the reasons for the longevity of PERL. If product A provides "only one way to do it", it can become inherently harder to integrate A to work with C and D. If B on the other hand is flexible, there's a good chance I can work around any issues, at least I have more options and tactics available to succeed getting the whole system up and running. So I'll choose B over A any day. It's genetically stronger. This is perhaps one of the problematic consequences of "programming by convention" that is often overlooked. It might get you up-and-running with something impressive to show quite early on, but try and do anything that conflicts with those conventions and by golly you're in for a hard time!

"Be flexible or die" - convention over configuration

Convention is not mutually exclusive with configuration, you can have the best of both worlds. If you think about what you're trying to do with JSF, it's putting things on a page in the right place doing the right things. And it's very hard to do. To be successful you need to make it really easy. Do you want JSF to be exclusive to only the top level of software engineers in the world? sounds interesting but does not work. The biggest mistake was terminating VWP. If there was a visual project it would end up driving the underlying implementation. I think it unlikely that it would be possible to create a VWP implementation given the complexities of the product as it exists today. If JSF is to be a world beater it has to be really easy to use, and it isn't at present. Another, issue I have is that I'd like to see some de-coupling from CSS. The component libs are doing some skinning but CSS is a complete nightmare really. Leave it for the .1% who need it. To address your point, sure, you sometimes need to delve in and do some special things, but how many tiers of complexity do you want? I want "really simple" and "potentially quite complex". I want to use the latter very rarely. Regards, Brendan.

Hey, that looks familar

Programming Perl, First Edition. My first book with my name on the cover (although I had ghost-written a dozen books before that).

Do you have a google alert?

Thanks for commenting! I'd love to know how you were alerted of the existence of this post. I'm quite certain that you don't manually subscribe to my blog entry, because, after all, you wrote the camel book.

You don't by any chance remember that session at SGI in Mountain View in 1995, do you?

The magic of Kibo

Yes, I have custom RSS feeds that watch for my name and the names of my books and FLOSS Weekly using the power of Google, which I read in Google Reader. I taught a lot at SGI during the first web boom, so I don't remember the *specific* session, but I remember being there. Oddly enough, my "Google Tech Talk" on git was done about 50 feet from where I used to teach at SGI, since Google HQ is the former SGI buildings.