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 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?:
The 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:
The 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…