SharePoint is one of the most successful and fastest growing Microsoft Server products, During the past 10 years; SharePoint has evolved from being a regular product to an extendable business platform that capitalizes & utilizes most of Microsoft products to deliver a super business experience for the enterprise.

A lot of practical cases proved that working with SharePoint for small/medium projects is very useful, it saves a lot of time; you can make a very rich, reliable & extendable application in few days with the least effort compared to coding everything from scratch.

Surprisingly, On the other hand; If we compare SharePoint Out Of the Box implementation with a normal ASP.NET implementation, we are going to find that a lot of technical people prefer to go with ASP.NET option or SharePoint Webparts with custom SQL database rather than SharePoint OOB implementation (Lists, OOB forms…) for the argument that is SharePoint projects are more complex and cannot be guaranteed to be delivered on time. I believe -initially- that this is true and here I am listing down -according to my technical experience- what are the reasons for this:

Before we go through the points let us agree on this:

“The success criterion of the right usage of SharePoint in a project should be measured according to how much Out Of the Box features are being used, otherwise; the decision of using SharePoint might be a big mistake and ASP.NET is supposed to be the right solution”

1. Missing comprehensive knowledge in the technical team:
   SharePoint is a big product that has a lot of business features; not knowing all those features can lead you to reinventing the wheel in many cases; in addition to knowing SharePoint market third party tools & community add-ins which might save months of development!
2. SharePoint project is simply an ocean of Workarounds:
   SharePoint is an ocean of workarounds! it is impossible to deliver an Out Of the Box implementation that satisfies your customer without making tons of workarounds.
3. ASP.NET background reverse effect:
   Most of the people who considered good “SharePointers” are originally ASP.NET developers who have a mature development experience and tend to follow practices that might not be suitable in SharePoint; not to mention that not understanding important concepts like content types, site columns, SharePoint designer workflows, out of the box forms & taxonomies…etc. can lead to wrong implementation.
4. High potential of Inconsistency:
   When you do Out Of the Box; the potential of getting spaghetti unstructured solution is very high, for example, in ASP.NET the code that does “Add“, “Update” and “Delete” is the same in all the pages, so if you understand one functionality; it would be easy to understand the rest of the pattern; In SharePoint; you might start by building 5 OOB lists and utilize OOB forms for DML operations, then after a while you discover that one of those lists has some complex functionality that cannot be achieved using OOB forms; so you convert it to custom Webparts. Another list is OK but needs a codeplex add-in feature to make it works 100% according to your customer’s needs! That what we call spaghetti implementation which is difficult to maintain & test.
5. Customers & analysis awareness:
   In many cases, Business Analysts (and some times IT background customers) are not that familiar with SharePoint business platform; so when they do analysis they think of it as a normal ASP.Net application (From scratch application) and they will end up with requirements that fit ASP.NET application rather than SharePoint; Business analysts should always “think SharePoint” and try to give solutions that are more supported by SharePoint, otherwise; we will end up with a week & crappy implementation which was better to be done in ASP.NET. (I am not saying that analysts should be “technology oriented” instead of “business oriented”, actually the business orientation should be dominant during the Envisioning Phase, but should be replaced by the technical orientation during the Design Phase).
6. ASP.NET simplifies developer’s life:
   Things are easier when dealing with a plain ASP.NET & SQL based implementation; For example, In ASP.NET with SQL DB, you can always empty a table by executing “delete from Table1“; in SharePoint you need to write more than 10 lines of PowerShell commands to do this, generally ASP.NET as a technology is more mature than SharePoint in terms of tools, resources & flexibility.
7. Complex troubleshooting:
   Troubleshooting in SharePoint is challenging (ULS logs, enable errors trouble shooting, event log… ) network issues, services & authentication… Endless stories & reasons for issues
8. SharePoint is an “Over-rich” platform:
   SharePoint UI gives u a lot of options and flexibility! This opens a very complex scenarios and increase the probability of end user misbehavior, In addition, a very mature testing plan which includes unit tests, integration test, performance test… and so forth is required, not to mention that this richness imposes a high level of governance plan to be available after delivery.
9. Difficult to estimate:
   Estimation is something challenging in general! But with SharePoint, it is something that few people can do right! in many cases a simple requirement that you overlooked could make you repeat the whole work; other times a codeplex tool or other third party tool can save months if you know it is exist!
10. Project Resources challenge:
    This issue can be summarized in four points:
    1. People: it is always easier to find ASP.NET developers than SharePoint developers.
    2. Hardware: SharePoint development machine requirement is extremely high compared to ASP.NET development machine, and that also applies on testing environment.
    3. Time: developers normally use visual studio to build & deploy many times during the day, moreover the time spent for building & deploying a SharePoint solution is normally double or triple the time for a normal ASP.NET application.
    4. Licensing: SharePoint licensing requirements are more expensive than ASP.NET Requirements, and my personal experience shows that 50% of project that I worked on was using licensing scheme  that is higher than what the project really needs! like getting SharePoint enterprise version instead of standard version or sometimes SharePoint Server instead of the free SharePoint foundation.
11. Complex knowledge platform:
    SharePoint seems to be an easy platform from the end user perspective, but unfortunately it requires a very advanced understanding of the most complex concepts of ASP.NET, database & windows server like memory management, caching, hardware capabilities & networking.
12. Complex Skills requirements:
    In SharePoint project you might need a complex criteria of development team skills : (C#, HTML, JavaScript, jQuery, CAML, CSOM, XSLT, power sell, batching commands, XML & Xpath…) and from Administration side as well (SharePoint end users skills, infrastructure, scalability, availability, security, firewalls, exchange ….) these skills are not easily found combined together.
13. Decisions, Decisions & Decisions:
    There are always a lot of big & highly influencing decisions that you need to take at the beginning of each project … Think of how you can do the following scenarios:
    1. A form with two text boxes & 1 button can be done by: Out of the box forms, Out of the box form with custom fields, SharePoint Designer Customized forms, InfoPath forms, BCS, Custom Webparts, Custom smart Webparts, SharePoint hosted app, cloud hosted app, normal HTML+JQuery, Page Viewer Webparts pointing to a custom application, Silverlight, third party based form like kaldeera.
    2. Creating a site can be done by: site definition, site template, PowerShell, custom coding or may be through the browser.
    3. Creating a list can be done by: list definition, list templates, PowerShell, custom coding or may be through the browser.
    4. Placing your configuration data can be in: web.config, site property’s bag, Webparts property or SharePoint list.
    5. Custom business can be placed in: event receiver, prevalidation(), client jQuery, SharePoint designer workflow
    6. Workflow can be implemented by: SharePoint out of the box, SharePoint designer, Visual Studio WWF, third parties K2 Nintex
    7. Data access can be done: object model (Linq to SP or CAML), web services, REST, BCS or CSOM.
14. Tools & Tools & Tools:
    SharePoint developers use a lot of tools (Visual studio, SharePoint Designer, office client applications, SharePoint manager, internet explorer, SharePoint log viewer, content deployment wizard, U2U… ) all these tools are helpful; but need a lot of knowledge, and when you mix things together. you will lose the control if you are not fully aware of each tool’s problems and capabilities
15. Administrative Richness Overhead:
    As a very flexible and rich platform; you need always to pay attention to a lot of issues that are not there with normal .NET implementations like (large lists issue, internet website JS and CSS file size…) application services running (Search Services, BCS, excel services…) and features based concept (scoping, dependency, stapling…)
16. SharePoint Branding is not easy:
    Branding is a very complex process which requires a lot of skills (CSS understanding, SharePoint branding artifacts structure like master pages, page layouts, publishing controls, CSS structure, themes, navigation…) and it is very rare to find the designer who can really understand this structure… and ironically; artistic & technical skills are usually inversely proportionate 🙂 (things are way improved in SharePoint 2013 but still not that ideal)
17. Complex security platform:
    SharePoint Security platform (groups, permission set, permissions, object level permissions) are a little bit confusing for new SharePointers; and fully understanding this is considered one of the ABCs of your implementation, considering that hiding an item from UI doesn’t mean that it is secured since it can be exposed in many ways (like search)! Not to mention that security stores are also not easy to be configured and challenging when troubleshooting if we go beyond active directory membership.
18. Deployment is a real pain:
    Deployment is one of the most complex processes in SharePoint; especially when you talk about out of the box implementations. ALM and source control is not easy as well; deploying version 1.0 might be -relatively- easy; but going beyond that (version 1.1) is very difficult specially in cases where you have data & content on production. The main reason for that if you compare it with normal ASP.NET application is that in ASP.NET, you are only concerned with dropping your DLLs, aspx, ascx, JS & CSS files into the right place then restore the database & you will be ok… then in version 1.1; you just overwrite those files (DLLs, aspx…) and with some little SQL skills you can run a custom script to add a table or fill a lookup or may be add a column to a table… In SharePoint; deployment is a totally different story!! Because the changes are a complex mix between files & “untouchable” SQL database in addition to having to write code & do a lot of PowerShell & tracking techniques to insure a right 1.1 deployment.

Some of the previous points are sad facts that we have to live with, but most of them can be cured if you do things the right way! So here we go…

Internet is full of blogs & articles on how to do a lot of tasks, but I have not seen a full life cycle application that describes an out of the box implementation that teaches you how to “think” SharePoint rather than to “Do” SharePoint, so this is the purpose of this series.