SharePoint’s Image Problem
SharePoint has an image problem with many folks.
I’ve discussed it before, but I think I have a new perspective on the issue.
You see, I recently interviewed a candidate that was Microsoft Certified IT Professional: SharePoint Administrator 2010 and Microsoft Certified Professional Developer: SharePoint Developer 2010. His resume looked impressive and promising, with many SharePoint projects under his belt.
He failed miserably on my moderate-advanced web developer assessment, skipping on nearly every single item in the assessment — things that I think any mid-level web/.NET developer should know.
You see, the problem is not that SharePoint is inherently a weak platform or inherently un-scalable or inherently poorly performing, but that they’ve made the platform so approachable, so well documented, and built such a strong community of developers and developer evangelists around it, that anyone can get into it.
You don’t need to know how garbage collection works or understand the difference between a Func and an Action (or even know what they are!) or what IL is.
You don’t need to know how to write a generic class or how to refactor code to reduce complexity.
You don’t need to know many of the higher level programming concepts of .NET or sound object oriented programming practices to build solutions on SharePoint because most of the time, you can just google it and find an example (Of course, most examples — even the Microsoft MSDN ones — are not meant for production code; they are merely designed to convey the concept and usage of a particular member in the library but not necessarily how to use it in an architecturally sound manner).
So therein lies the root of SharePoint’s image problem: it’s so easy to build basic solutions, a developer who is fundamentally weak on the .NET platform and fundamental web technologies like Javascript and CSS can be productive in many companies and even get Microsoft certified! And then these developers are let loose on projects that ultimately under-deliver in one way or another. Be that performance or usability or maintainability.
SharePoint is like the mystery basket on Chopped. There is nothing inherently good or bad about those mystery ingredients but for the skill of the individual chefs who combine them through the application of experience, creativity, and technique to create a dish. With different chefs, you will get drastically different results each round and the winners are usually the folks that have a fundamental understanding of the art and science of flavor and cooking as well as a deep understanding of the ingredients.
It is the same with SharePoint; it is nothing but a basket of ingredients (capabilities or features) to start from (a very generic one at that). At the end, whether your dish is successful or not is a function of whether you have good chefs that understand the ingredients and understand the art and science of melding the ingredients into one harmonious amalgamation. Likewise, it is important that when staffing for SharePoint projects, you focus not only on SharePoint, but also on the fundamentals of .NET, computer science, and good programming in general.
You can also think of it like a Porsche. Give it to a typical housewife to drive around a track and you’ll get very different results versus having Danica Patrick drive it. Should it reflect poorly on the Porsche that the housewife couldn’t push it anywhere near the limits? Or is it a function of the driver? Danica Patrick in a Corolla could probably lap my wife in a Porsche around a track.
The bottom line is that SharePoint, in my view, is just a platform and a good starting point for many enterprise applications. When some SharePoint projects fail or fall short of expectations, the blame is often assigned to the platform (ingredients) and not to the folks doing the cooking (or driving). SharePoint is indeed a tricky basket of ingredients and it still takes a skilled team of architects, developers, testers, and business analysts to put it together in a way that is palatable.
