Sunday, August 5, 2012

The Rules of SharePoint [Fight Club]

I was talking recently with a fellow SharePoint developer who specializes in custom SharePoint development. In other words, this means he probably spends more time with the SharePoint Object Model than SharePoint SharePoint [Fight Club]Designer, for instance. I was remarking on the fact that even though I too am a SharePoint developer who is well-versed in the nuances of Visual Studio and the object model, many of my client’s needs tend to be solved by leveraging no-code solutions. I went on to talk about the value of no-code solutions from the perspective of farm stability, risk, and deployment issues.

What surprised me was that, as he agreed with what I was saying, I could sense what appeared to be a ‘light bulb’ moment going on his head. Why would this be a novel idea to a true SharePoint person? I mean, isn’t this exactly what the 2nd rule of SharePoint is all about?:

imageThe 2nd Rule of SharePoint: At all times, leverage the out-of-the-box platform whenever possible.


This principle, I believe, is at the heart of what it means to truly be a SharePoint developer. In fact, whenever I lead development teams on SharePoint projects, particularly when some of the team members are .NET developers attempting to re-purpose themselves for SharePoint projects, I try to drive this point home. Because, although a .NET developer can certainly ignore almost every SharePoint paradigm, and forcefully bolt a custom application into a SharePoint page, developers need to understand how counterproductive this can be. Many organizations for whom we create solutions, whether they knew it or not, may have just spent a considerable amount of money implementing an enterprise SharePoint installation for the purpose of leveraging all the power that SharePoint provides. To ignore the benefits of building on top of SharePoint is to ignore the investment made by our clients, and in effect ignores the vision of SharePoint as a rapid development platform.

Now, you may be wondering: “So, what’s the 1st Rule of SharePoint?” I’m glad you asked:

imageThe 1st Rule of SharePoint: We Don’t Talk About SharePoint!


That’s right – in many situations, if at all possible, we should try to keep the name “SharePoint” out of the forefront of the minds of our customers. As I mentioned in a previous article, we should focus on the solutions that we’re delivering, which just happen to be using SharePoint. Otherwise, the name of SharePoint may bring with it certain presumptions that may not have anything to do with our solution.

Also, as we’ll start to see with the 2013 suite of Microsoft products, the boundaries of a ‘SharePoint solution’ are going to blur as the power of SharePoint becomes a more integrated combination of SharePoint on-premise, SharePoint in the cloud, Office, and Azure. It’s going to start to be too counterproductive to constantly call out the different technology names to our clients in order to describe our solutions. And at the end of the day, how much do these back-end technology labels matter to our end users?

Stay tuned for even more SharePoint [Fight Club] rules in the future…


  1. good one. even i had the same experience working with developers. They think this is quick and easy way. Instead of exploring OOTB soln.

  2. SharePoint's Prime Directive is: "Empower the business user to self-reliance and self-sufficiency." That should be the focus of any custom solution that a SharePoint developer creates.

  3. Great post. I agree with both of your SharePoint Rules. Perhaps rule #2 could be renamed the "No Code" rule, but that would conflict with the corollary to Rule #1 --- We don't talk about No-Code Solutions.

    You are right that end users as well as managers, line of business owners and execs ONLY care about the results. They are interested in the solution first and that you (as a services provider / consultant) can implement it second ... then they'll ask about the underlying technology.

    Sure, there is a need to insure the technology being considered is inline with the skill set of the IT team, but more and more there is a need for solutions first and tech second.

    The bottom line is (perhaps this can be rule #3) ... Customers Pay For Solutions

    Let me know if you would like to collaborate on Future SharePoint Rules. We can certainly add something about needing more Cowbell ... because you can never have too much.