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