SharePoint sucks revisited

It’s been a while since I blogged about SharePoint, and thankfully it has been over a year since I last had the misfortune of working with it. I’ve had time to reflect and without a doubt I can say Sharepoint sucks. Here are the main reasons:

SharePoint does everything, just not very well

What exactly is SharePoint, A CMS? A DMS? An intranet? An application framework? A workflow system? A task list? A database? Or a wiki? SharePoint rather than being 1 product, is more like a collection of haphazardly slotted together mini apps. In short, everything is there, which looks great on paper, but each component lacks quality.

Misunderstood and underestimated

I’ve worked on enough SP projects now to understand the trend. At first there is a general enthusiasm towards a SP project. This is because if you’ve never worked with SP, then from a management perspective it seems like a great starting point, which will require only a few tweaks here and there to become a functional product. From a developers point of view, it at first glance appears to be just another CMS, that you can customize with relative ease. That is until you’ve actually worked with it.

Everything is convoluted

I can honestly say, I’ve never worked with a more confusing and mind numbingly over complicated (unnecessarily) product before. Believe me when I tell you (and no exaggeration here) from a developers point of view, SharePoint is a parody. If you’ve seen the series Faulty Towers, then John Cleese’s frustrations dealing with a somewhat bizarre little Spaniard are minor in comparison to the frustrations any SP developer faces when dealing with the “devil of all software”.

Another analogy comes to mind, and that is that if the sun, moon and all the planets were perfectly aligned and down to the last millisecond brought forth the perfect conditions for the antithesis of good software architecture then that product would be SharePoint.

Let’s get specific:

Lists and their definitions

Once you start getting into professional (take with pinch of salt) SP development, you’ll naturally want to bundle up all your lists, content types and fields into a WSP package. All these definitions are XML – awesome! Except not so awesome because that xml (especially for lists) needs to include most of the plumbing. If you’ve had any experience with WCF 3, then you’ll know that if was hard to configure, and by the time 4 came out, a lot of the required stuff in 3 was removed and replaced with defaults. This made WCF 4 much easier to use. Ironically none of this love was spent on SharePoint.

Now a SharePoint list is supposed to resemble a database table, in the sense that it stores tabular data. Databases however are logical. In every RDBMS that I’ve worked with, the field definitions are comprised ONLY in the table definition.

However since in SP it is possible to host multiple row types in the form of content types, in the same list. The content types and their corresponding field types are defined separately, Each with their own unique GUID. To make matters worse content types have a proprietary inheritance naming that you need to understand, or things don’t work.

Also since SP is more confused than a boy lady bug, you need to define the field and content types, both separately and then again reiterate these same definitions as part of the list (SP data table).

This means a tedious amount of work.

Web Application, Site Collection, and Site

Now this theory is covered when you first get into SP, mostly in 1 liners. At first it is confusing. The Web Application appears to be a Web Application in IIS. But then if that is the case what is the site collection? Is the site a virtual directory? But to make matters worse deployment needs to take place at different levels. And will greatly impact on if your application will actually work or not. A lot of this is hit and miss and you usually figure this out when things don’t work as you expected. This is because no one has the time to learn all this upfront prior to starting a project.

Long winded deployment process

Didn’t work? IISReset /Noforce? Did you re register the feature? Is it enabled? Did you unregister the last one? So you think powershell to the rescue, only in powershell you need to manually code in the thread sleeps to give each execution time to run because the calls are async. Still even if you’re well setup, a huge amount of time is wasted in deployment during development. Simply because this isn’t the copy to webserver, hit f5 refresh type of deployment you love, not at all.

Won’t run (or not supposed to run) on a desktop

For this reason, nearly every SP developer works in a VM, usually on some cheap laptop with the bare minimum amount of RAM. Needless to say performance is dismal. Things don’t get much better in production. SP is a resource hog of note, which is why when a framework like WordPress might run on an old 486. SP requires an entire farm to run smoothly.

This ain’t Farmville

Farms seem transparent enough on paper, however as any SP developer knows, nothing is that simple. No matter what you can expect some issue sooner or later with deployment at the application level. Typically DLL’s not quite making it to the corresponding GACs of all application servers in the farm.

 The query language is too nothing short of parody

Out of all the query languages I’ve come across CAML has to be the least intuitive. I’ve also only ever seen it used with SP. I guess it doesn’t have a huge following.

Take this SQL statement: Select * from customers where (active = true and hasPurchased = true ) or (active = false and reason = unhappyCustomer)

Seems logical even to a non developer, the same query would look something like this in CAML:

<or><and>active=true<and>hasPurchased=true<or><and>active=false<and>reason=unhappyCustomer

But to make matters worse, the ORs and ANDs are grouped into 2: So it isn’t uncommon to see statements like this:

<Where>
    <And>
        <Or>
            <Eq>
                <FieldRef Name='FirstName' />
                <Value Type='Text'>John</Value>
            </Eq>
            <Or>
                <Eq>
                    <FieldRef Name='LastName' />
                    <Value Type='Text'>John</Value>
                </Eq>
                <Eq>
                    <FieldRef Name='Profile' />
                    <Value Type='Text'>John</Value>
                </Eq>
            </Or>
        </Or>
        <And>       
            <Or>
                <Eq>
                    <FieldRef Name='FirstName' />
                    <Value Type='Text'>Doe</Value>
                </Eq>
                <Or>
                    <Eq>
                        <FieldRef Name='LastName' />
                        <Value Type='Text'>Doe</Value>
                    </Eq>
                    <Eq>
                        <FieldRef Name='Profile' />
                        <Value Type='Text'>Doe</Value>
                    </Eq>
                </Or>
            </Or>
            <Or>
                <Eq>
                    <FieldRef Name='FirstName' />
                    <Value Type='Text'>123</Value>
                </Eq>
                <Or>
                    <Eq>
                        <FieldRef Name='LastName' />
                        <Value Type='Text'>123</Value>
                    </Eq>
                    <Eq>
                        <FieldRef Name='Profile' />
                        <Value Type='Text'>123</Value>
                    </Eq>
                </Or>
            </Or>
        </And>
    </And>
</Where>

Like I said this is SharePoint, so you can expect it to suck.

Taxonomy sucks too

Ah the hidden list, and the sync issues – just Google it.

The general quirky nature of it, things I’ve forgotten about

I just remember always feeling like I was wrestling a bull while working with SP. Nothing ever just slotted into place. Everything seemed over complicated and required way too many manual steps. In short a ton of energy for a small bit of functionality.

I’ve forgotten about all the odds and ends, but at the end of the day SharePoint just sucks and there are much more cost effective and less frustrating solutions out there.

 

5 thoughts on “SharePoint sucks revisited

  1. Thanks for your SharePoint observations. I have had similar experiences, i.e. SharePoint has many features, but none of those features work well. Have you found a preferred alternative to SharePoint, or do you just use separate apps for different functionality? Thanks!

    • In my experience there are some viable options to Sharepoint, but it depends on what you’re using it for. Jira and Confluence combined form a viable alternative to the backbone of an intranet and issue tracker. Confluence can replace virtually all of Sharepoint intranet functionality.

      The main issue is that most “Microsoft shops” who are most likely also gold partners want to play in the Microsoft box. You as a developer will find it virtually impossible to convince an entire team / mid management and / or senior management that they should avoid SP at all costs.

      So unless you’re the one calling the shots or have some organisational clout, this is the main deciding factor on why Sharepoint gets used, because those who decide to use it, those with the ability to sign off on technology see no other viable option and are looking at it purely from a capabilities report, and how bad can it possibly be?

      It is also at the end of the day “an application framework” – so managers buy into the idea that they start with functionality already provided and can build on that. So trying to push a custom solution from scratch will too be virtually impossible.

      It is only months / a year in that teams start to turn and managers start to see their projects taking longer than anticipated and things going sideways. At this stage though usually any clients involved / teams involved are already fully committed / past the point of no return and now even more time is required to push out that solution.

      Then once they’ve spent 2 years on a project that should take 6 months. After this point any budget has already been spent fully invested into Sharepoint, and now recommending a new brave solution cost wise might not be viable, and time wise absolutely not.

      I know this sounds a bit like worse case scenario, but it is more common than you think.

      • Michael – Thank you for this information. It doesn’t sound like a worse-case scenario to me as I have also seen it happen with other products too many times as well. I will check out Jira and Confluence. Thanks again for your feedback! Lloyd

  2. I’m a former “sharepoint guy” who, while having moved on to other endeavors in IT (strategy and architecture), still intersects with sharepoint a fair amount. As such I’m confronted with the 2013 apps model, which by my reckoning can be summarized as “write a html5 app that calls services hosted elsewhere via javascript and inject this markup into sharepoint as content”. Which could also be summarized as “the 2013 apps model for sharepoint is to write the bulk of your app on other platforms”, which could also be summarized as the 2013 NON apps model, or perhaps as a just plain stupid concept. At least that’s my understanding, arrived at independently and supported by the SP developers with whom I interact.

    Anyway, looking for material to confirm or deny my estimation of 2013 apps, I stumbled across your post. And, as I former sharepoint guy, I concur WHOLEHEARTEDLY with your assessment!

  3. “I’ve worked on enough SP projects now to understand the trend. At first there is a general enthusiasm towards a SP project. This is because if you’ve never worked with SP, then from a management perspective it seems like a great starting point, which will require only a few tweaks here and there to become a functional product. From a developers point of view, it at first glance appears to be just another CMS, that you can customize with relative ease. That is until you’ve actually worked with it.”

    Ha ha! So true. Exactly my experience as a developer when I foolishly suggested to try Team Sites as a cloud solution to a customer. Halfway through the project I wished I hadn’t. They had 365 so it seemed logical to use the free sharepoint service included.

    OMG!

    They had an app on it – Artezio Help Desk. It never worked – it would hang when trying to update a request. The fixed was to use the browser back button and start it again. Needless to say the customers were not impressed with any of it. Never again!

    Not only that, but Microsoft are renouned for scrapping their technologies, so they just pull the plug on it one day, like they did with their team-sites website hosting. Another

    /Jason

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s