A couple of years ago, when I was first starting to work with SharePoint, I overheard a conversation in the hall at my company. Will was talking to a few other people and asked this question: "What’s the difference between a developer who knows SharePoint and a SharePoint developer?"
At the time, I thought he was splitting hairs. But as I’ve gained some experience, watched my own approach to SharePoint development evolve, and worked with others who are ramping up on the platform, the more I think that question is pretty relevant . SharePoint is, after all, just a very large ASP.NET application, so it stands to reason that experienced .NET developers should be able to jump in and be productive reasonably quickly. That’s largely true — but I think the answer to Will’s question lies in the details of the solutions.
For example, take application configuration. Experienced .NET developers hear that and think web.config file entries; sophisticated folks might even use custom configuration sections. (I know: I’ve used them. Do I consider myself sophisticated? Uh, no.) However, work with SharePoint for awhile and config file entries start to get on your nerves. No, they’re not a huge deal, but it’s annoying to have to make them for every new web application or, in farmed environments, on every web front end server. Oh, I know there are approaches for this, or you can always use the SPWebConfigModification class to try to make your changes, but the cost-benefit is often questionable; how much code do you want to have to write/test/support to add two AppSettings entries to a config file? There’s another issue, too: a standard SharePoint backup doesn’t grab files from the file system, so using a config file means your site’s configuration now has to be backed up in two parts.
My observation has been that those who have been working with the platform for awhile are trending other directions. SharePoint MVP Chris O’Brien recently released a config store solution in which configuration items are stored within a SharePoint list. I worked on a project recently where we used extension methods for SharePoint API classes (see Talha’s recent post on this) to wrapper configuration items stored in the property bag of the SPWeb class. The point? In either of these solutions, the configuration items are easy to create/read/write from custom code (e.g. a FeatureReceiver class) AND are part of the SharePoint content database which will be backed up by SharePoint’s standard backup procedure.
Another area in which I think there’s a difference between a developer who knows SharePoint and a SharePoint developer is in the area of solution packaging. I know for me, the more experience I’ve gained, the more I follow the best practice of wrapping all customizations into features and solutions. That’s not something I did from the start — nor frankly, did I see the value in it. I think packaging is another area where there’s definitely an evolution of perspective.
What do you think? Are there other areas that differentiate a developer who knows SharePoint from a SharePoint developer?
