Scott Jamison

A common question I get is “why do SharePoint service pack updates take so long?”  The main reason, of course, is that unlike a service pack for, say, the Office client, which only needs to update the binaries, SharePoint needs to take two steps:  1) update the binaries, and 2) update the database schema.  While the database is being updated, SharePoint is down.

A new article on TechNet, published today, provides some best practices for minimizing your downtime.  It’s primarily for enterprise scenarios where avoiding complete downtime is critical. The article describes how to configure a mirrored Office SharePoint Server farm for minimal downtime during an installation of software updates by temporarily setting the content databases in a secondary farm to be read-only (while consuming shared services from a parent farm). It’s not perfect, since users can’t create or modify content. But at least they can get to their data.

I was in a customer meeting the other day helping evaluate one of their SharePoint sites that seemed to be running slowly (3-5 second response time instead of 1-2 second response time).  I asked about customizations that were done to the site when the customer said the following (to paraphrase):  “Yes – we built and installed four custom solutions, and there have been no performance code reviews on the custom code.”  No performance testing?  Or code reviews?  This is one of the many mistakes I’ve seen when it comes to custom solutions built on top of SharePoint.  Here’s why:

If you’re looking to build a business solution with SharePoint, you have two choices:  color within the lines or color outside the lines.  What do I mean? 

Coloring “Inside the lines”

SharePoint does so many things out of the box (that are relatively easy to configure) that it’s easy to get spoiled.  For example, I can provision a website, add permissions, add several custom data lists, drop in some out-of-box UI elements (web parts), add an aggregation (via the content query web part), configure a customized workflow, and show some KPIs (key performance indicators) all without any code.  In fact, I may be able to complete my solution without any custom code at all.  Wow – that was fast.  And since all I did was some customization using out-of-box tools, I can get away with cursory testing.

But hold on.

Coloring “Outside the lines”

The minute I recognize that my SharePoint-based solution needs an element that is not out-of-box, I may need to write some code.   Let’s say that customization gets me to 90% of my solution.  That’s okay, since I’m only having to build 10% of my solution (instead of 100%).  But as soon as I cross this line, I need to recognize that custom code requires a certain level of discipline that customization simply does not.  What does it require? Things like:

• Performance testing (does my code introduce performance issues?)
• Code reviews (is the code documented well?  is it written well? will it upgrade?)
• Best practices (is the code checked into source control? are all bugs eliminated?)
• Proper need (did I write code that I didn’t have to?  is there an ISV solution to close the gap?)
• Proper architecture (did I use the object model correctly?  should I use a particular feature that I neglected to use?)

Keep these items in mind when attempting any custom code with SharePoint.  Custom code is a good thing — just make sure that when you cross the line from customization to code, you do it in the proper fashion.

Here are some important resources regarding best practices with SharePoint, including the recent update to the Patterns & Practices guidance on MSDN.  In fact, check out the code acceptance checklist.  How many of these do you check before deploying your code?  Be honest!

• Patterns & Practices – SharePoint Guidance
• Code acceptance checklist
• Team-based development for SharePoint 2007