SharePoint is a Colossal Piece of Shit and Should Not Be Used by Anyone

I have a hard time, occasionally separating my facts from my opinions. That being said, I think I can make a compelling case that SharePoint is a colossal piece of shit and should not be used by anyone(tm). First, a bit of my background... I started programming at about eight years old writing simple BASIC programs on a TRS-80. I graduated to writing assembly language and then stopped coding for several years. I took one course in Computer Science at the United States Air Force Academy, got an A, and then never bothered setting up my PC again for several years. I graduated from college, got a job, and then I found out how hourly rates for people who could program ABAP (SAP’s proprietary programming language which looks an awful lot like COBOL). I spent a good year trying to convince people that in spite of the fact that I do not have a Comp Sci degree that I am a good programmer.Somehow, I succeeded in my quest and spent several years as a professional developer in SAP. Y2K came and went and so did my programming career.

Several years later, I was asked to develop a simple expense submission application in SharePoint. SharePoint was selected as a platform because the company I was working for liked to follow every worst practice by Microsoft. Later, I worked on several large scale implementations of SharePoint in Australia and I can say, unequivocally, that SharePoint was always the wrong platform and while it does a lot of things, it does all of them poorly. So, in order of importance...

SOURCE CONTROL AND DEPLOYMENTS

My background in SAP is going to show here. SAP is far from perfect, but one of the things it does exceptionally well is version control and deployments through their basis system. As a developer, every change I made in the dev environment was attached to a transport. When I was satisfied that my configuration changes or code changes were working correctly, I could release my transports. These changes would then be migrated to the test environment. If all went well, the changes would then be migrated to production.

On my largest of several SAP projects, there were regularly scheduled migrations on Tuesdays and Thursdays at 4PM. At about 3:50, someone would walk around saying, “Save your changes, we’re going to release transports in ten minutes!” I would try to finish up whatever I was doing and then I would walk away. I’d go outside or get a cup of coffee or whatever. I would leave my computer for about fifteen to twenty minutes, and every time I came back, the system was ready for me to start working again. Each of these scheduled deployments were a complete non issue. The fact that I am praising this may seem strange, but I have worked on plenty of projects where deployments could take hours or even days. Each deployment seemed like a herculean effort and they never seemed to go right. It seems obvious, but being able to set up distinct environments for development, integration testing, user acceptance testing, production,and optionally sandboxes is not always done and yet it is critical to good development.

In the .NET world, the preferred method of source control is Visual Studio Team Foundation Server (TFS). There are mechanisms for doing deployments to a server and managing it through TFS, however, there is no way to do this for SharePoint. At best, a developer can set up a Virtual Machine that is based off of a production server and then do development work in the VM. Everything can then be bundled into a .WSP file and that .WSP file can be uploaded to a production server, but this mechanism is inexcusably sloppy.

Ideally, any change that is made in development should be available for deployment from code to a configuration file. Since it is only possible to bundle code, it is entirely possible and extremely probable that a configuration file would be modified in development and not on production. Therefore, the .WSP bundled file may work perfectly in dev but not where it counts. Note that I am only talking about dev and production here as the mechanism for deployment is so bad that I can’t possibly imagine a dedicated testing environment.

I have seen an extremely gifted programmer come up with a solution that was comprised of several hundred lines of powershell script to handle deployments. As I said, the developer was very good, but there was always drama with the deployments. The fact that all the custom script had to be written in the first place shows how immature SharePoint is as a platform. If the platform does not have a mechanism for creating environments and handling code AND data migrations, it should not be considered. Period!

Sadly, it is really easy to do some things in SharePoint. Want a new team site? Click a few buttons and voila! No problem. This gives the impression that you can create entire elegant solutions quickly and easily, but going back to my point here, if you cannot manage your environments, then you wind up doing your development and testing in production or find things that work fine in one environment don’t work when you try them in production. It almost forces developers into worst practices while setting expectations from management sky high.

Lists are not relational

Creating lists that can persist data and do rudimentary validation is an absolute breeze in SharePoint. That’s too bad because, again, it gives the illusion of being useful, but lists are awful to work with and lead to horrible applications.

A leading retailer in Australia created a list to handle stock transfers. In a sane system, there would be two tables - a stock transfer header and stock transfer items. The header would contain some basic information about store transfer from, store transfer to, requested by, created on, etc. The items table would then contain the quantity and product SKUs. In the sane, relational world, it would not matter how many items there were. A stock transfer could have one item or it could have fifty. The model will handle either scenario equally well.

Alas, the sad retailer chose to do this on SharePoint and it was done in a list. The list had 150 columns in it and allowed for 30 items in the transfer. The columns asked for the information I identified as belonging in the header and then had columns like SKU1, quantity1, SKU2, quantity2, SKU3, quantity3, and so on. The form the user entered had a hard coded 30 fields regardless if there was one item in the transfer or 30. If there were more than 30, then a separate transfer had to be completed.

So what, you might ask? Yes, it might look ugly, but what does it matter. Well, it matters in the sense that if you ever wanted to ask a business question like what is the most requested item for transfer, it couldn’t be done. In the relational world, the SQL statement to answer the question is trivial. In the list/non-relational world, a product could be in any one of up to 30 columns and the query would have to look in every column to provide the answer.

Speaking of querying lists... Lists reside in SQL Server, but you cannot directly query them. If one writes a C# application that needs to access SharePoint list data, it can be done. In SharePoint 2007, it was done through a goofy implementation called CAML query which, while not particularly difficult to write, is painful to test or modify (but when you’re developing in production, who cares about testing). In SharePoint 2010, the CAML query was more or less dropped in favor of Linq (not to be confused with Microsoft’s corporate instant messenger application Lynq) which was neither better nor worse but different. However, neither system lends itself to simply exposing the list data in a way that can be accessed by SQL. It makes accessing said data difficult to write and test and seems a bit pointless. And yet, it gets worse as lists don’t scale particularly well and Microsoft recommends not using lists larger than 5,000 items - the default list view threshold established in SharePoint 2010.

SharePoint looks like shit

Like most web applications, SharePoint has a master template that can be modified to give the site a particular look and feel. Except SharePoint throws certain things into the default master and it’s not very obvious or intuitive as to what can or cannot be changed. Out of the box, SharePoint looks awful, so just about everyone wants to change it, and yet it takes a ton of effort. Meanwhile, if one were developing on another platform, Twitter’s open source Bootstrap is gaining a lot of traction. There are many free Bootstrap themes that are available, but for less than $20 per theme, one can choose templates that create a very professional look and feel with tons of choices (https://wrapbootstrap.com/). If your site was developed on Python, Rails, Java, or even .NET; I would put aside a few hours to integrate the theme. On SharePoint? Good luck...

SharePoint is not cheap

It’s usually a bad sign when there is no accurate way to get an estimate for what a SharePoint implementation is going to cost. At a minimum, it requires a SQL Server, a SharePoint Server, and a $100/ year/ user license. Then, since it looks shitty and doesn’t really do anything, there is the added cost of implementing it. Then since most implementors are hacks working on a crappy platform and all customizations are not supported, there is the ongoing costs of maintenance.

I have an inside source who used to work at Microsoft Consulting Services who claims that 35% of all SharePoint licenses are “naked CALs”, or put in other terms, companies buy the license and then never actually install it because it costs way too much and it is a pain in the ass. In fact, my friend went on to write applications that work on SharePoint pitching the product to CIOs as a way to claim a successful implementation.

Intangibles

Even now, in its fifth major release, SharePoint does not work on Windows. That’s right, SharePoint only works on Windows Server. If you are developing SharePoint applications, you have to create a VM on your workstation and do your development inside the VM. While not necessarily a show stopper, it seems clumsy and creates some administrative overhead and requires additional setup times and issues with connectivity.

Further, there are plenty of scenarios in SharePoint that have not changed over the years. Google did an amazing job back in 2004 with showing the world how to use AJAX (Asynchronous Javascript And XML). Essentially, when a user loads the gmail client, the page does not refresh, only the elements do. This was absolutely amazing nine years ago, but SharePoint has not caught on. Go to a standard document library and click new. The browser refreshes and a new page is loaded. The user can select a document and upload it only to get redirected to the original page. Maybe I’m nitpicking here, but the product really should take use of AJAX, but I doubt the product managers at Microsoft really care. They are too busy integrating the Office toolbar or Silverlight or something else no one cares about.

Conclusion

Since SharePoint does not have a good mechanism for maintaining multiple environments and since lists are not relational and do not scale; SharePoint is best used as a document repository. Yet, it looks bad and requires a lot of work to make it semi-decent. In my humble opinion, the best thing to do would be to use Dropbox and integrate it with Active Directory at a fraction of the cost and none of the headache.