We've talked about why you should not write custom code for SharePoint 2010, now let's consider the reasons why you should (or could) write custom code.

My recent article: 3 Reasons to Not Write Custom Code for SharePoint 2010 caused some debate both here on CMSWire, and further afield on the web. In it I discussed the key reasons that you shouldn’t be writing custom code for SharePoint. In a nutshell I argued:

  1. 90% of problems can be solved using out of the box functionality
  2. Writing custom code is not for the faint hearted or ill prepared
  3. Custom code imposes an unnecessary shelf life on your solution

I concluded by saying it was wise to think twice before firing up Visual Studio. So what if you think twice and still want to write custom code? When is it appropriate? Well I think there are three clear areas where custom code is OK.

1. Branding and Design

Everyone wants to brand their Intranet. SharePoint systems are no different. I have argued before that branding is a balancing act and too much is a bad thing. But a sufficient level of branding can be perfectly sensible and can actually enhance a portal or Intranet. Making an Intranet on brand will give users a warm fuzzy feeling from that start. It can help tie the tool in with other systems and offer a uniform interface. It can present familiarity, and even corporate authority.

Extranets and such have an even stronger case for branding. Their use is typically by external staff, contractors or freelancers. Exposing these people to your brand can help build awareness, and can give direction over what a system is for and what it does.

Custom code to achieve these aims is fine. As stated, I would advise caution, and not treat your Intranet/Extranet as a website. I wouldn’t overly customise it, nor would I move too far away from the standard look and feel. But a custom master page or two, logos and background images, and maybe a custom navigation, can all work in the system's favour.

2. Interfacing with Line of Business Systems (LOB)

A common use of SharePoint is as the ‘glue’ between multiple systems, an interface between existing line of business systems and newer SharePoint based functionality. These applications can be interfaced with in a number of ways. Friendly ‘out of the box’ ways include Excel and Access services, but particularly ‘business connectivity services’ (formally the ‘business data catalogue’) and its related web-parts. (Check out: 4 Ways to Integrate External Content with SharePoint 2010)

But sometimes custom code needs to be written to communicate with these systems. Maybe they are difficult to create connections to, or require custom web-parts to display their data and outputs. Maybe SharePoint is to act as a full read/write terminal to an old system. Business connectivity services will get you so far, but more complex requirements like these will require your own code.

Functionality such as this is often key to the success of portal or Intranet projects. If a slew of custom code is required to get the old back office talking to the new back office, then it may well be worth the investment. That is until you retire those systems and move the functionality naively into SharePoint.

3. The Limits of SharePoint

I’ll admit that sometimes you will hit the limits of what SharePoint can do. You need a web-part to read out the time in 13 different countries whilst displaying photos of the CEO's holiday. Or more likely your client has some very bespoke business requirement that no one has yet solved. I would still strongly advise you consider solving 70% of their problem using out of the box functionality, if possible.

But we live in a far from perfect world. Sometimes clients demand it all, even when we know better, and custom code is the answer. Just promise me you're not going to spend your time building yet another weather web-part. This problem has been solved, it's called a ‘window’.