50 reasons why I don't like SharePoint development

I was introduced to SharePoint in 2001 when it was called SharePoint Portal Server 2001, codename Tahoe. From time to time I have been put on SharePoint projects but I never came to like it.

I think I have worked on more than 10 SharePoint projects, some of them fairly big. The last time I used SharePoint was back in 2011 with SharePoint 2010.

This blog post is not intended as an evaluation of SharePoint with a socio-technical economic corporate or whatever perspective. SharePoint might, or might not, be a good choice for your development project. This post is Not about SharePoint as a viable product. This post is solely about what I think about SharePoint as a development platform.

Please note that I am talking from my experience as a developer who happen to like simplicity, structure and who cares about usability. What you will find here is simply my personal view of SharePoint development. This is based on doing deep custom SharePoint development, not just configuring out-of-the-box SharePoint sites. Also note that this blog post was written before the release of SharePoint 2013.

Not just me being an old crank
Even prominent people within the .Net community such as Carl Franklin and Richard Campbell openly say what they think of SharePoint. In .Net rocks podcast episode 734 Richard Campbell makes the following joke: "The thing about SharePoint is you start on having a problem you think you can solve with SharePoint and then you have two problems."

Richard Campbell even goes as far as to say SharePoint makes you cry.

You'll even find developers of SharePoint at Microsoft out right saying: "It is not, and never will be, a viable developer platform."

The 50 reasons why I don't like SharePoint development and why I'll hopefully never do any more of it:

1. SharePoint kills creativity with its configurations. Flicking on xml/xsl files is not very inspiring.
2. The backend user interface is mostly not very intuitive. I as a developer don't like to develop systems that suck.
3. SharePoint as a framework is too big and complex and you never get to feel that you master it all.
4. The product is pricy and too big so I can't use it for my private projects. That means I will not be able to reuse the skills on my hobby projects.
5. SharePoint experience has limited transfer value for other type of development projects. 
6. There is usually IT politics involved since it's a big decision to start building the competence and infrastructure. With politics often follow dirty games, power struggles etc.
7. SharePoint requires lots of training and long-lasting changes in the behaviour of users. This means that you don't get to see the results of your work and how users actually end up using the system. By the time the use of the solution has stabilized you are long gone on other clients, other projects or have left the firm.
8. Once an organization and the development team has acquired SharePoint licences and competency they tend to reuse SharePoint on other IT projects where SharePoint is not the best fit. SharePoint often becomes overkill and results in very large development costs. You as the developer may end up having developed a system that is doomed to fail. 
9. Organizations who have acquired SharePoint for their internal systems often want to reuse the platform for their public facing website to consolidate their infrastructure/licenses. It brings with it a large overhead and the public facing website becomes too complex to manage , maintain and evolve. You as a developer might get stuck doing boring support or very difficult maintenence.
10. Agile methods can become problematic. SharePoint content types cannot easily be changed once it's in production or even in testing environments. This means projects have to be fairly waterfallish.
11. Difficult to write unit tests. Poor separation of concerns.
12. SharePoint version 2010 does not support .Net framework 4.0.
13. The platform is resource demanding and becomes slow on your dev machine, especially if you have a VM setup.
14. Debugging is slow. Timeout occurs. When attaching the debugging you'll often hook on the wrong w3wp.exe.
15. Poor HTML rendered. Takes LOTS of time to customize rendering.
16. No Asp.Net MVC support (unless you are only using the SharePoint API) .
17. Heavy frontend html/js/css that runs slowly in the browser.
18. Lots of XSL files. I never liked XSLT.
19. Making control adapters is a headache, must deploy but then reactivate web app feature to deploy app_browsers file. compat.browser with control adapters debugging often don't work.
20. The ghosted/unghosted feature of content types is a big headache.
21. Some super users will have the rights to change contenttypes, delete site columns, delete or move lists. This is dangerous if you have custom backend code that uses these lists.
22. Very difficult to investigate content in the database when debugging.
23. Often you do not need workflow, content approval and document versioning etc. All these things make the solution more complex and you will have to remove or deactivate these things if you don't need them. Scripting removal/deactivation takes time.
24. Lots of things happening under the hood that is not documented very well. New developers, not familiar with SharePoint will often make bad choices that will be very hard to fix later.
25. SharePoint requires a lot of competency so you often have persons specializing i various SharePoint fields and often you'll have parts of the IT department that do SharePoint maintenance/operations tasks. This creates dependencies between people and you often get stuck waiting for other persons or departments to deploy or do other development tasks. If the required person or department is unavailable you are of course stuck and you look bad.
26. Memory leaks are easy to add (although there are tools to find them), App pools regularly crash.
27. Packaging and deployment is of course different from anything else. Additional competencies needed.
28. The sheer magnitude of the product is difficult for developers. You'll need different third party tools. All the knowledge required is overwhelming.
29. When the site goes down or suddenly become slow after an upgrade it is often very difficult to pin-point the error.
30. The log file (ULS) is always filled with a ton of entries and you have no idea what half of them are. The ULS log is typically 2000 lines long and the error messages are very bad.
31. The API returns data that are concatenated and needs to be parsed.
32. Has to run on Windows server. It can run on Windows 7 but not really straight forward to configure your local environment if your team has a good continuous integration setup.
33. Unpredictable system performance. When you have performance problems and investigate you will often not find the problem because there are just too many moving parts. Suddenly the performance is better. You look at automatic database tuning, at changes in content and changes settings/configurations. You look for memory leaks, do performance testing in the testing environment, restore different versions of the production database, you look at visitor statistics, web server logs, sql logs, application event logs, ULS logs, look at timer jobs, various manual jobs that can have been started, you look at users behaviour during the period, you check automated response testing like Gomez, what's hitting your site, crawlers, what content is being read, when is backup and indexing on the database running. Has the MOSS search crawler been running etc but the problem is often a mix of interrelated issues so it's hard to find by investigating sub systems one after the other.
34. SharePoint has too many configuration options. An example is regional settings on each site. You might get problems showing dates consistently and not understand why.
35. Lots of access control and post release configuration required. You'll have to determine what content types, site templates, page layouts, webparts should be allowed to use by who and where.
36. If you on a page want to hide fields that are empty or add some conditional formatting you'll have to create custom webparts or usercontrols. Webparts that should be hidden in special scenarios requires additional development.
37. Some out-of-the-box webparts (such as search) creates poor html which makes them harder to style and look a like on different browsers.
38. Since everything is customizable in SharePoint you end up with less user friendly dialogs. For example if you use a very simple page publishing workflow there are still going to be superfluous user interface elements and interactions that makes it messy for the user.
39. Ambiguous error messages.
40. In a script-it-all dev environment you often configure some part of the SharePoint solution and to test it you do a deploy of the entire site by building it from scratch or running some upgrade scripts. You find that the configuration you just wrote did not work for some reason. The scripts takes 20 minutes to run so you spend the rest of the day tweeking the configuration files to get it to work by running the deployment scripts over and over.
41. Setting up a sitedefinition always seems to be a problem. Settings up a new sitedefinition and configuring what features, page layouts, content types, master pages, welcome page should be used for a site seems like a straight forward job. But this for some reason always fails and you have to modify the configuration and redeploy and redeploy and redeploy until you get it right.
42. A single typo in a setup config file can destroy your site and will be hard to locate.
43. You are using a very large platform and you can't just copy one installation to a new site and start from there.
44. In most cases you will start by reconfiguring the site from scratch. So most of what you do is to write code or configurations to build and deploy your site instead of spending time developing cool features using cool code.
45. It is difficult to script everything. There are simply to many customizations and configurations that can be done. There is always some manual change that someone forgot to script.
46. Too many layers of development. In other projects you might just have to copy the entire site, make some adjustments in a few config files, then set up the database and you are good to go. But with SharePoint you will have to write code that builds the things that builds your solution (unless you are doing simple projects using the SharePoint designer).
47. The whole development process tends to get messy because things are just hard and complicated with SharePoint.
48. Creating Internet facing websites are difficult because the platform has a lot of overhead. Lots of effort to go around things, removing things and making the site more accessible and faster.
49. Because SharePoint development is so complex things very often takes more time than estimated so you miss deadlines or have to work overtime.
50. If you have a SharePoint project with high expectations on visual design, usability or accessibility then you will require designers with good knowledge of SharePoint. This can be hard to come by and/or will require excellent collaboration between developers and designers. Often challenging.
51. Microsoft usually makes big changes to SharePoint with each new version. If you have not followed best practices you are in for lots of work if you are upgrading in the future. What the best practices are takes time to learn.
52. The preferred way to store data in SharePoint is with SharePoint lists. If you do not use lists and instead go with separate databases you can end up with a fragmented solution with many databases (SharePoint warranty breach if you meddle with the internal SharePoint databases). If you use SharePoint lists you are likely to run in to issues with the abstraction layers and problems trying to put relational data in lists.

Further reading

http://www.cmswire.com/cms/information-management/the-art-of-sharepoint-success-10-reasons-why-sharepoint-projects-fail-012592.php
http://codebetter.com/jefferypalermo/2007/09/13/sharepoint-is-not-a-good-development-platform

SharePoint or Asp.Net MVC for building a new and simple web site

I was recently on a project where we were faced with the choice of what platform to base a scoped down prototype web site on. Based on the team competencies and the fact that we had already developed several SharePoint sites for the customer we were basically down to two choices, SharePoint or developing an Asp.Net MVC site from scratch. I consider Asp.Net MVC superior to Asp.Net so a regular Asp.Net WebForms project was out of the question. SharePoint is mainly a collaboration solution best suited for Intranets and portals. Even so, many companies use the platform for their company website because of the growing amount of SharePoint developers and other benefits of the platform such as extensibility.

The purpose of this blog post is to share knowledge for others who might be faced with the same choice of using SharePoint or Asp.Net MVC for a very small web site with few requirements.

About the team
We were 4 developers, a scrum master, a part time interaction designer and a part time graphical designer on the team. None of the team members were SharePoint or Asp.Net MVC specialists. None had any experience worth mentioning on SharePoint 2010. The average experience in years with programming of the team members were less than 10 years. Most had worked with SharePoint for some years but none of the team members had in-depth expert knowledge on all sides of SharePoint development.

A short note about the scope of the project
Time span of the project was about 2 months including planning, design, development and testing. Without going to much into details, here are the features of the site:

• Integration of some external social media widgets.
• Very basic publishing of simple content.
• Branding and fancy visual design.
• Some commenting, mailing list sign up and feedback features.

The site was a pilot project so we did not have strict requirements on quality assurance etc.

Platform choice
The decision was to use SharePoint as most of the developers were more familiar with SharePoint over Asp.Net MVC. The decision was inline with the company IT-strategy and most of the developers were keen on trying out the new SharePoint 2010.

Experiences
At the time of the project it just happened that I was starting a new hobby project using Asp.Net MVC on my spare time so I had the opportunity to compare SharePoint and Asp.Net MVC development side by side. The two projects were similar in many ways. In the comparison below I only discuss issues that are relevant to both platforms. Many of these problems have also been encountered in previous projects so they might be said to be typical problems you might expect to run into.

Problems we encountered while starting a new SharePoint 2010 project

• We had to switch to a new development environment and install Windows 7 since SP2010 requires Windows 7. Installing Windows 7, setting up SharePoint and configuring all your nice to have software typically takes two days.
• We later got licensing problems for the OS and Visual Studio. This is not a big problem but all of these small non-code related things combined make a lot of noise.
• SP Feature mess: We had trouble setting up page layouts. It kept getting ghosted automatically. We found out that some meta tags attributes on the page layout caused it to automatically getting ghosted during deployment. This resulted in several wasted dev hours.
• SharePoint has a lot of built in JS such as the init.js file. One of the social media widgets we wanted to use would not run along side the SharePoint JS on IE7. Debugging minified widget code and thousands of SharePoint lines was not anything we wanted to do so we had to write some custom code. Again several hours wasted on debugging and custom development.
• SharePoint 2010 still renders bad html and lots of other page elements, js and other markup that is not needed for a Internet facing site. The site even tried loading Silverlight when used as an Internet facing site. Chrome crashed because of the Silverlight plugin. This was fixed by adding a SPSecurityTrimmedControl around the ribbonrow.
• We added several web parts to the web part gallery and we encountered problems that made the add-webpart ribbon unusable since the add button got hidden beneath the ribbon bottom edge on some browsers.
• We encountered problems with the NoteField. We wanted more than 255 characters for the text. When deciding to use the html rich text field instead we had to change the content type and this is not a walk in the park if you have already created some test pages you would like to keep.
• Each time a new content type field is added there's often problems for the other developers. The other developers need to upgrade their solution.
• VS caching bug. While doing deploy from SharePoint within VS we sometimes got this error: deploying Activating feature 'OurFeatureName' ...
• Error occurred in deployment step 'Activate Features': The field with Id {e3575ee4-1b6e-43fc-b243-77f727f33e16} defined in feature {a36d44c1-b523-4235-950a-59ed763d2588} was found in the current site collection or in a subsite. This error had to do with some state being cached by Visual Studio 2010. In this case we had to restart VS.
• SharePoint includes a bunch of js and css files. To optimize page rendering on the client we cleaned up and customized the minimal.master masterpage using editmode controls etc.
• We created XSL for the Content by Query (CBQ) web parts and had to figure out why the CBQ didn't list our pages. Debugging this was time consuming.
• We also had problems with web parts not being deployed because of inconsistencies between .dwp and .webpart files.
• Another problem related to web parts not being deployed had to do with mismatch in the SP2010 .spdef files that might be caused by code merging problems.
• A typical error many do on SharePoint. XSL files packaged incorrectly and end user in anonymous mode don't have access to the xsl.-files and the page breaks.
• Then we had problem with the server. The system was a small pilot project so the server we got was an old outdated server. SharePoint 2010 simply did not run on the old server without extensive reconfiguration.
• We copied a SharePoint feature from another project. We forgot to change a GUID and things just did not work. Debugging, again not trivial.
• SharePoint 2010 does not support IE6 so we had to add a custom warning message for IE6 users. The lack of IE6-support has in retrospective been a problem because it also resulted in down prioritizing IE6 for the front end anonymous view of the site and we have got several complaints from end users who did not understand why the site looked bad on their browser. Also showing of the site is also problematic because the company still used IE6 as the default browser so this lead to embarrassment as we didn't always have control of the installed browser at the location where the web site was presented.
• The page layout or list we tried to add at some point simply would not be added to SharePoint. No easy way to figure out what was wrong with the xml. The schema.xml for a list is not particularly pretty and inviting to work with. There are of course tools to help you with this but the work all becomes very complex and awkward unless this is the only thing you do for a living.
• Then, one of us had problems updating the web.config. Updates did not affect the site on the developer’s machine. After an hour wasted work we found out that SharePoint 2010 use a different web.config file. The new web.config file is under the layouts folder in the 14 hive.
• Next problem; SharePoint redirected mobile devices to a mobile site by default so we had to customize this also.
• Then we got problems on the Publishing Images doc lib. Some unexpected error occurred when navigating to it. Still don't remember what was done to fix it. Simply too many problems and solutions to keep track of.
• We had a lot of static html code that were inserted in content editor web parts. Part of this static html was some javascripts used for client side paging and other GUI effects. In SharePoint this had the affect that the JavaScript altered the content of the web part while the user was editing the web part. When saving the web part the user would be saving the jQuery altered version of the html. To fix this we had to link to a separate file instead and update this one rather than editing the web part content itself. With Asp.Net MVC this would be a simple text field with html. The wysiwyg of SharePoint just made things more time consuming here.
• As with other typical SharePoint projects we had to set up content types, set default page layouts for a page library, what page layouts are available for a site etc. All these things take time to configure in the site definition. This is typically tedious and boring work.

Problems I encountered when starting a new Asp.Net MVC project

• First problem: You code everything from scratch this can be a frightening enough it self. Using some sample code as a starting point might help a lot.
• You get 'Object reference not set to an instance of an object' errors and you can't figure out what is wrong. Asp.Net MVC uses a lot of convention over configuration so there's a lot happening under the hood. Debugging this might be difficult because there a lot of abstractions and inner workings that you might not want to dive into.
• More convention over configuration problems. If you miss a convention or have a convention implemented wrong you will often not get a compile time error message and it’s difficult to locate the error.
• Figuring out how the routing works on XP with IIS5.1 is difficult. Not very intuitive if you are still on XP.

Conclusion
Asp.Net MVC is simply a web application framework. SharePoint is a software platform for collaboration and web publishing and has a rich set of capabilities out of the box. So basically what you are doing in SharePoint development is to customize the existing features, tweaking features, overriding stuff, extending features or even stripping them way. On Asp.Net MVC, on the other hand, you develop the site basically from scratch. For most developers it will be more interesting and exciting to develop something from scratch that they have full control over, not having to abide by the complexities of SharePoint and having to sit and configure XML files all day long.

If you know that you are going to use some built in feature of SharePoint you should consider SharePoint, but if you are not going to use any of the strong selling points of SharePoint such as document management, workflow, compliance, publishing, document search etc you should definitely build it your self.

Benefits of Asp.Net MVC over SharePoint for small and simple web sites

• Asp.Net MVC uses convention over configuration. In most cases this makes development very fast as the conventions reduces the work to be done as well as providing a model (MVC) for architecting and for how to arrange code in a consistent and clean manner that further reduce complexity and speeds up development. Faster development means cheaper development and enables early testing which is important for a prototype.
• You feel more productive as everything you do has a purpose and is directly affecting the solution. Every line of code has direct impact on the actual feature you are working on. SharePoint xml configuration is often used to configure some feature that you don't even need in the solution but you have to configure it anyway just because it's there and available be default to users. A lot of tasks on SharePoint simply seem like a waste of time since you are not working on the required features but instead on removing the features that are not required.
• Most developers find it more fun to write code than writing XML. When writing code you get to be creative and show how good or smart you are. With XML configurations you have to stick to the schema, no room for creativity.
• By using Asp.Net MVC we would have Azure as an alternative or backup hosting model.
• SharePoint development requires a lot of competency. To customize a SharePoint site you need to know web development as well as XSL, the SharePoint object model, feature stapling, site definitions, WSP packaging, SharePoint security model and a bunch of other things. Since very few developers are experts in all of these areas it takes a lot of coordination and teamwork. More dependencies means more development time.
• A part from the social aspects and skills required there are the complexities of the technical solution it self. In general, SharePoint introduces a lot of complexity that makes development less fast. Lots of different type of code in different places, lots of classes, lots of different configurations on different levels, various tools such as STSADM, lots of scripting commands to remember, many folder locations. Lots of concepts and features. If you want to look into the database to try figure out what SharePoint is doing you'll also meet a wall of complexity there also. More complexity equals developer headache.

Benefits of SharePoint over Asp.Net MVC for small and simple web sites

• SharePoint has a lot of built in features, some of these might be exactly what you need. For example, Web parts that can be moved between web part zones was one such feature we made use of.
• As with all IT-projects you must take into consideration future requirements. SharePoint's comprehensive platform might be what you need for your site in the future when your site grows larger and features such as versioning, document management etc may be required.

The big take-away from this blog post

Complexity = more development time.