SharePoint As a Development Platform Debate

There's a very heartfelt debate raging at CodeBetter.com over whether SharePoint is a good development platform. The breakdown seems to be between "developers" and "SPs" or "SharePoint People".

Jeffrey Palermo kicked the discussion off by discussing what he feels makes a good development platform and then contrasting those points with the current state of SharePoint 2007 development.

I can understand the concerns of those who don't feel it is an ideal development environment. One of their biggest issues is how to manage the artefacts that SharePoint generates, especially the settings that can be made via the browser but not easily replicated to a source repository for sharing and versioning.

Many of these changes only live in one of SharePoint databases and so are hard to track. It goes against a programmer's mindset when these things are intangible and hard to track and synchronize.

Microsoft and the community are releasing more tools that can help manage this and perhaps in Office 14 there will be some easy facility to export and import configuration settings as an XML file. This would make it simpler to do proper change management with SharePoint.

There is also the fact that SharePoint is good at glossing over a lot of very complex interactions. Running underneath the hood is a SQL Server database, web services, a complex object model, Windows Server interactions, office integration, ASP.NET and Windows Workflow Foundation, a series of providers...it's very complicated but SharePoint makes it look easy. So when anything goes wrong somewhere in the stack it can be hard to figure out. In this sense it's a victim of its own success at abstracting the lower level plumbing.

The best SharePoint solution results occur when the customization points are kept in line with the core things SharePoint does well, such as workflow, collaboration, search, content management and publishing, and document management.

Whenever possible I recommend limiting SharePoint customization to things that can be done via the browser or through modifying XML or XSL properties (for instance for Search Results web parts). This also helps to protect the solution from service packs and future versions of SharePoint as any customizations are likely to be minor and easily tracked (and upgraded).

When new requirements come in, it's helpful to have the entire team of SharePoint developers compare notes on what the platform allows and how it can be customized. It's noteworthy how many times a 30-minute requirements-gathering discussion can end up with a shared agreement on how the out-of-the-box SharePoint components can be combined to deliver something that at first blush seemed to require half a dozen custom web parts.

The fact that so much can be done with so little effort actually makes SharePoint a killer development platform - the trick is to use a bit of imagination to align as much as possible to what SharePoint provides and go with the SharePoint flow. If SharePoint development is difficult and painful it's probably time to reassess the proposed solution to see if there's a more elegant, SharePoint-centric approach.

Anyway, there's a lot of fascinating insight being posted on Jeffrey's blog and anyone who hopes to develop on the SharePoint platform should at least give it a look. The full discussion thread is here.