Thoughts on the Microsoft Approach

To me, Microsoft Products have always had some common ground and guiding light. Microsoft's motto over all these years has been all about having products with a very user friendly interface and products that provide very quick and direct advantages, with little or no development time.

So...why aren't all products like that? Well, nothing is perfect, so sometimes having things that simple, have disadvantages. Working hard to solve the top 80% scenarios, will usually leave the other 20% in bad shape.

What does that mean in practice? Basically, you can give your customers great value for money if their scenario fits the scenario Microsoft predicted. If the configurations allow you to configure that simple thing they asked you to change. Otherwise, you may be in trouble. Changing that small thing may be close to impossible sometimes. You may need to do your own custom development from scratch, while having something that close OOTB.

So, in relation to SharePoint, how does that affect a Developer or Consultant?

In my own view of things, a SharePoint Developer should not be a standard Developer. For that matter, in almost all the platforms I have worked with, the same principle applies.
A SharePoint Developer shouldn't be focusing only on the code itself or in the best way to deploy SharePoint artifacts. Its job should be to know the platform very well, and first of all, knowing all of the platform's abilities and OOTB components.

One would say: if Microsoft is pushing SharePoint in so many business areas and to serve so many purposes, isn't it impossible to know everything about the platform?

In my opinion, yes. To become a 'de facto' expert in some of the areas explored in SharePoint, you will need several years of experience, and every day you may still be learning something new. That's just the way it is. But the goal here is to understand where your efforts should be placed. And in my opinion, you should strive to understand the full SharePoint experience.

If you are just developing custom Web Parts, you will also gain a lot if you understand how OOTB SharePoint Web Parts behave and how you can leverage them. You shouldn't have to rely on the Functional Consultant to tell you what's there OOTB to solve the problem you have in hands. You will provide more and better value by knowing it yourself and being able to take advantage of everything that's already there.

This may seem intuitive, but it is hardly applied on the real world. The example I gave here is about a SharePoint Developer knowing the OOTB platform, but also applies even within each role's responsibilities. For instance, SharePoint Functional Consultants who have been largely involved in Collaboration projects will gain huge value if they understand and know what's there in terms of Web Content Management and Enterprise Content Management. Because when you deploy a SharePoint farm with a Standard or Enterprise licence, you are offering you customer a very wide range of functionality that can be used for multiple purposes.

The best example I have on this is the Publishing Feature. All the Collaboration projects I have worked in so far, with a Standard/Enterprise licence, I have recommended having that feature enabled. The functionality it provides OOTB is easy to understand and, even if Pages are not the core of the project, this feature provides a number of advantages that will always be very useful.

Now, going back to the SharePoint Developer. If he focus more on the platform and less on code, what will he lose?

He will obviously be a less experienced coder than someone who develops 24/7 using C#, Java or Ruby on Rails. Maybe his patterns and best practices knowledge won't be as deep as those guys. He should still invest on that, but not as a "full time" thing. Balance both worlds is the best approach, at least if he is committed to developing for platforms. There is a high number of SharePoint projects that involve zero coding and a number of them where you'll end up with just 3 or 4 pages of code.

Knowing where to place yourself to maximize the value you provide is key.