I have been working with SharePoint 2007 since the first beta came out. The tools and methodologies available for development have improved a lot since then, but I still see a lot of organisations that haven’t quite got a handle on how to use SharePoint as an effective development platform.

In working with various clients over the past few years, I have come up with a set of principles that can ensure a SharePoint system both supports initial requirements and continues to work well after a year of use and customisation. Most of these will be most relevant in the planning stages of a project, although I have on several occasions been called in to implement these principles after a system has become unstable.

  • Treat SharePoint components like any other code - Source control is often omitted from SharePoint projects, and manual deployment is far too common.

  • Maintain the environment in a supported state - Debugging is very difficult when you can’t tell what is deployed.

  • Control access appropriately - What users and developers are allowed to do has a big impact on code quality.

  • Make good development easy - Security policies that prevent development environments connecting to source control are not a good thing.

  • Develop with future changes in mind - Most functionality can be implemented in more than one way, and usually one way is much easier to change later. Don’t build a system that will be impossible to upgrade.

  • Avoid duplicate effort - You can use SharePoint’s collaboration functionality to improve communication between development teams and facilitate development of reusable components.

  • Do basic technical design before confirming requirements - The SharePoint platform makes some requirements very easy and others very hard. Don’t agree to build the hard ones before you know how hard they will be.

I will be going into more detail on each of these points in a series of posts over the next couple of weeks.