My friend Joy Earles (@joyknows on twitter) recently proposed a question to me that she was proposing to several people in research for a presentation she was preparing. The question: What would you say are the primary strengths and weaknesses of OOTB customization vs. SPD vs. custom code? Since there are so many ways to answer this question, I thought it would be a good idea to write up a blog post with my first response by instinct, but also allow others to contribute to the answer, you may have other insight into this from a different perspective.
If you don’t know by now, I am primarily a SharePoint Administrator, so my answer comes from the perspective that keeping the farm running smoothly is my focus. With that in mind, my first instinct was that the two biggest risks of customizing SharePoint are performance and upgrade (including patching). I know I know… security falls in there somewhere, but I am basing this on the assumption that security was implemented properly, and would continue to be.
The OOTB (out of the box) customization that is done from within the browser, which includes adding and removing web parts, adjusting the theme, changing the navigation, etc… is the least risky of these methods of customization. It poses no real risk with upgrade and patching since you are not modifying anything that SharePoint does or the object model. The bigger risk here is performance. Although with training this can be minimalized, it is still a very real risk. Despite how many times you repeat “don’t click the X, that only closes the web part, it does not delete it from your page” users will still do this. When a web part is closed, it still is loaded when the page loads, you just don’t see it. I have had users call wondering why their page loaded so slowly when they only had a few web parts on it. Luckily, when you get these calls, there is an easy way to see what is going on. Simply add “?contents=1” to the URL of the page, and you can see what web parts are added to the page, and what ones are “closed.” Then you can remove those closed ones and the page should load more quickly.
Customization using SharePoint Designer (SPD) poses slightly more risk than OOTB customization. The risk is still present with performance, but in this case, for different reasons. Back in SharePoint 2003, there was the ability to use SPD to customize, and the terminology then was “ghosted” and “unghosted” with ghosted being the better of the two. Today, the terminology has changed, and is “customized” and “uncustomized” with uncustomized being the better of the two. Susan Henry has a great post on this here. Basically what happens is that uncustomized pages are rendered from the content that is stored in the contend database in combination with the files that are stored on the server. However, customized pages store those changes to the files in the content database and are rendered from there. Now, this may not seem like much of a performance hit, and in many cases, it is slight, but it should still be a consideration when customizing. Along with this comes the risk when upgrading and patching. During the upgrade from 2003 to 2007, unghosted or customized pages caused issues, you had to re-ghost these pages before the upgrade would complete. I don’t know if this will be the case with upgrade to 2010 yet, but I would measure that risk carefully when considering customization. Also, many organizations use SPD to “brand” their SharePoint sites with their own logos and colors. Now, if this is done correctly, it should only be a slight risk for patching, but upgrading to the next version of SharePoint will break this and you will have to have a new branding solution ready for deployment when you upgrade. Remember, though you should never modify the 12 hive files to brand your site, these can be replaced at any time with patches, so this poses a definite risk!
Customizing using custom code, usually Visual Studio and C# code, is the riskiest of the 3 methods. You are now generating your own code, using the object model, and affecting the way that SharePoint works. This is definitely a risk when upgrading and patching. You will have to test very thoroughly to make sure your code will still work after upgrade or patching. Administratively, this adds more overhead, and should be a definite consideration for customization. The best way to minimize this risk is to have any customization be packaged as a solution (.wsp file) before deployment. This will allow you to retract the solutions and even remove them if they are causing an issue with upgrade. The risk to performance is also greater with custom code. If your developer does not properly dispose of object (make them use spdisposecheck!) you can end up with memory leaks. Again, packaging as a solution allows you to easily retract the solution while your developer corrects any issues with performance as well.
All in all, as long as you know the risks, and how to limit them, compensate for them, and recover if disaster strikes, customizing SharePoint is NOT a bad thing. You just have to know when to take that risk. Go ahead, be the gambler!