People Want Different Things
Dan Antion (@dantion) did a great post over on his SharePoint Stories blog this morning called People Want Different Things. Dan does one excellent post per week on that blog. They arrive every Saturday morning, and reading it is usually one of the first things I do of a Saturday.
Today’s was a great post, as always, and prompted me to write a comment, much of which turned into this post. Dan’s post hits on something I feel very strongly about: there is no one-size-fits-all concept with SharePoint.
There are many, many people out on SharePointLand who seem to think that there is one way to do any one thing in SharePoint. Usually it’s the way that they know best, and is sometimes the way that they are selling (though sales people in SharePointLand seem to be far more ethical than in the other lands I have visited).
This mindset can apply across many dimensions: development, branding, information architecture, process implementation, you name it. There’s a reason people joke about what I and many other SharePointilists usually say, but the right answer is almost always “It depends.”
In Dan’s post, he gives the three main ways he approaches most of his SharePoint work (I won’t repeat them here, read Dan’s post), and I happen to know that there are favors and variations on the three (the jazz masters have nothing on us SharePointilists) and there are probably a fourth and fifth or more some days, too.
And that’s Dan’s point, I believe. Using SharePoint has some science to it, but to a large degree it’s more art than science. Anyone who marches into a new client, project, or meeting thinking they positively have the answer up front is more than likely wrong. SharePoint is a collaboration platform first and foremost – which can make it frustrating to use in other ways – and building stuff in SharePoint ought to be a collaborative process. I call that collaborative development, and whether you label it with other buzzwords like Agile or not, I firmly believe it’s the best approach.
So it’s not just that People Want Different Things; it goes beyond what any one person likes. It’s what the right answer turns out to be. Sometimes you don’t truly know that answer until you have finished. Of course, work on SharePoint-based solutions should never really be finished, but that’s another another post for a different day.
good point. I have worked with quite a few “SharePoint Developers” with a .NET background so to them every problem can be solved with a coded solution. It’s important to be aware of all the options and then guage what will work best based on the users, the environment and other factors.