Collaborating on Building SharePoint Solutions

1 minute read

Bjørn Furuknap, never the shrinking wallflower, posted an article today about SharePoint Configuration vs. Development.

One of the things that always seems to be missing is the bridge between the two approaches.  I’ve lived on both sides of the wall, and as long as there’s a wall, things fail.  SharePoint is a collaboration platform, yet it’s amazing how infrequently I see people collaborating their way toward a solution.

I’m a HUGE proponent of what usually gets called customization and that’s where I choose to play the game.  That doesn’t mean that I can’t or won’t write "code", it just means that in the majority of cases, I don’t think you need to.  (BTW, I don’t know why it is so, but apparently XSL, JavaScript, jQuery, CSS, etc. aren’t "code".  I think that’s horse pucky.  Code is code is code, and you need to do the right things regardless which one you choose.  For gosh sakes, words are code: look at the trouble people get into using *them* incorrectly.)

So the key, to me, is to understand the portfolio of tools you have at your disposal and which is right for the task at hand.  Don’t use a hammer to drive in a screw.  There’s also a *lot* of middle, fuzzy ground where the right answer might be the one that is going to get you to a solution that works OK in a reasonable amount of time.  So maybe you use DVWPs instead of custom Web Parts (or vice versa) from time to time.  As long as you are actually solving a business requirement, everyone wins.

To paraphrase Rodney King, “Why can’t we all just get along?”


Have a thought or opinion?