SharePoint Sucks – And Here’s Why – Part 2

OK, so the first post in this series seems to have caused a bit of a stir, and a lot of comments and emails suggest that I’m out to sabotage or that I’m just trying to get attention by trolling as the SharePoint-hater.

Nothing is further from the truth. I really, truly believe that SharePoint sucks.

Before we go any further, however, I’d like to just clarify what I mean by ‘sucks’ as opposed to, well, ‘not sucks’. I’m not looking to ‘define’ my way out of anything, I simply want to clarify the properties I think sucks about SharePoint.

In my mind, a good product is a product that is both effective and efficient. As such, the age-old statement about “you’re using it wrong” does have a lot of merit. If you expect SharePoint to cure cancer and give you a date with Denise Richards then you will be disappointed.

Unless, of course, Denise Richards has a thing for people who are proficient at SharePoint. I certainly haven’t received a date request, but then again, I may not be proficient enough.

This does not mean SharePoint sucks. If your expectations are wrong then you need to alter your expectations, not blame the product. If I wanted a collaboration solution and installed Minesweeper, of course it wouldn’t fulfill any of my requirements, but that doesn’t mean Minesweeper sucks.

However, a product should perform the tasks it is delegated, within its feature set, to the best of its abilities. SharePoint doesn’t.

1.  SharePoint sucks because SharePoint is sold as a product.

Damn people to hell for showing customers a team site or a collaboration portal. I spend days telling people that a team site is _not_ their requirements specification.

Don’t look at a solution and say that it is what you want. Say what you want and then look for the solution. SharePoint may be the answer if SharePoint meets or exceeds the requirements, but in too many cases people say ‘SharePoint’ first and then ask someone to tell them what they can get. That’s putting the cart before the horse.

2. SharePoint sucks even worse for showing people how incredibly easy they can customize and configure their sites, list, libraries, pages, workflows, and features.

Giving people that much power without the barrier of needing a working brain is disastrous to any organization. Power without a plan is just lightning.

When, in the mid-90s, people learned how easy it was to create a web site using HTML, designers and web developers had a hard time convincing organizations that having a web strategy is a complex matter. I mean, all you had to do was put some stuff in between BODY tags, so why all the fuzz about user experience development, interaction, standards, and all the other cost-increasing stuff that doesn’t seem important?

3. SharePoint sucks because of all the people who show of fancy-schmancy features and promise the world, just to sell a license or a consulting gig.

Customers are easily impressed and sold when a salesperson, whether that person is a consultant or a bone-fide seller, demonstrate how easy it is to hack together a working proof-of-concept. When a real architect or developer enters the project, customers are shocked to learn that developing a SharePoint solution is nothing different from any other software development project and is a lot more expensive than the impression left by the sales process.

When shit hits the fan, blame is easily placed, but the customer is still left without what they want. So, the customer is asked, again, to adjust their requirements to meet the solution.

4. SharePoint sucks for not utilizing its incredible potential any better than it does.

I mean, SharePoint could have been the real business productivity killer app that everyone really wants, but instead, it is cumbersome and riddled with either faulty or awkward development methods that are alien to most people without years of SharePoint experience.

This is the point about performing to the best of one’s abilities, and I’m going to give a couple of examples here.

SharePoint is an ASP.NET application. Except it’s not. SharePoint has far too many exceptions to that rule, making experienced ASP.NET developer cringe and new developers scared. You need to learn SharePoint development; being a master of ASP.NET will only get you part of the way. For new developers, that means you have to learn both ASP.NET and SharePoint development before you can get anywhere.

Note that this isn’t unique to SharePoint; many so-called ASP.NET applications suffer the same problem.

SharePoint is a front-end to custom data and can be used to model organizational data and processes. Except it’s not. The database-mimicking features of SharePoint leave so much to be desired that MySQL seems like a very feasible option.

The workflows used to ensure business process management are either extremely limited (SharePoint Designer) or extremely complex (Visual Studio). This means that customers again need to either limit their requirements or pay through the nose for someone who can design and develop workflows properly.

I could go on for quite some time, but I’ll end part 2 of this rant now and pick up in part 3 later. In the meantime, however, I do love to get your feedback and thoughts, so keep comments coming, either here or by email to furuknap<[at]>gmail.com. You can also hook up on twitter (@furuknap) and let me know how you feel there.

.b

NOTE: This article is part of a series. Make sure you read the entire series to get the full picture, especially the thrilling conclusion in Part 4.

People who just get half the picture are, well, half-witted.

Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

24 thoughts on “SharePoint Sucks – And Here’s Why – Part 2”

  1. I can't help but notice, but only point 4 is actually about SharePoint! The top 3 are about its marketing, and the industry as a whole.

    I agree with all the first 3 points, but with the caveat that the same is true for many other products too. Heck, 2 and 3 are probably true for most commercial software!

    Point 4 is also true, and I agree that it is a problem. Development is a royal pain in SharePoint. The technical learning involved is pretty extreme to achieve basic competance. I see basically good devs making 'mistakes' just because they didn't happen to know a particular quirk about SharePoint development. I frequently find myself scratching my head at some bit of behaviour – and I reckon I'm a pretty solid SharePoint dev.

    I hope that the tooling for 2010 might make this better – and we don't have to rely as much on community projects to make basic development tasks possible (thank God for WSPBuilder!) We'll have to wait and see.

  2. OOTB SharePoint offers a lot features, but we have never had a client that didn't ask for more. Writing custom code for SharePoint is like wearing handcuffs, although it is built on top of the .Net 2.0 Framework there are many limitations like non-relational data that have you developing code that is more geared toward fixing SharePoint's short-comings. The amount of "hoops" that you have to jump through to get simply tasks done is mind boggling. I often think the ROI on custom developing is not justifiable.

  3. You'll probably leave us dangling till the last part of your rant, but I'll ask anyway: If SharePoint sucks, what other solution is there that can offer the same or even better outcome?

    Taking into account all the side benefits, like standardization, 1 external supplier instead of many, worldwide available expertise (and certifications), and so on of course.

    About development: I recently attended the DIWUG in The Netherlands where an MVP said: Use basic Sharepoint functionality and start building from there. It's still a pain in the ass, however, you can decrease the pain per iteration and at the same time show the customer what he can and can't do, leaving the choice to him wether or not he wants to spend a lot of time and money on developing additional functionality.

  4. Anonymous,

    Without knowing the requirements I cannot say if a solution is better or worse than anything. If a requirement is to have a good time, Minesweeper certainly is better than SharePoint.

    .b

    1. I couldn’t agree more. I can’t come up with another product, that people explicitly suggests others to NOT use. These people don’t suggest any other specific product which proves that they are not promoting a competitor to SharePoint. They just wan’t to help others not to jump into the same hole.

    2. Buggy ?!!! That is such an understatement. I have been fixing sharepoint for the last year and half. If I am ever asked in an interview if I can do sharepoint I will tell them proudly that I have never heard of it !!!!

      What does it do well? NOTHING !!!

      What does it do ? – almost everything according to marketure. Proof that better mousetrap never makes it to market (for you that like analogies).

      Any user I have ever talked to asked me why they would ever have to use such a confusing application, so can I please make it look and work like a real web application.

      My CIO thinks it’s great. He uses email and Power Point. I have never seen him use sharepoint. When I ask him details of how to do any sort of thing in sp, he cannot answer but still insists it’s great.

      My hobby at work is replacing all sharepoint applications with real ones that just work. Actually not a lot of effort to do so by the way

      Oh by the way, I’ve been writing Microsoft code professionally since Windows 1.0. Maybe I just have to get in to the Microsoft mindset, huh ?

      1. It is absolutely a product that’s popularity is based on executives who “love it” but don’t use it and who can’t even use Excel without the help of their admins.
        Sharepoint is the Emperor’s New Clothes.
        My husband & I have both been writing code since Windows 1.0 too and just can’t convince the higher ups that this produst is not the manna from heaven that they think it is.

  5. Considering point 2.. what do you recommend? Having a system in place where everything is locked down? Where the users can't express their creativity to solve their own business problems because the system won't allow them?

    I rather see people using SharePoint to solve their business problems than using Excel and/or Access.

  6. You obviously have too much time on your hands… but not enough to tell the masses what other solution is "better", given the requirements SharePoint is designed to fulfill…

    Troll somewhere else.

  7. Regarding Point 2 –
    This is one of my biggest gripes with IT professionals. IT professionals honestly believe that if we're not around to hold hands of the user-base they'll never be able to put on their pants. Frankly, the user-base isn't our parents, but rather our peers, and to assume they are all stupid because they don't know the action bar versus the top menu bar is just arrogant.

    Users, in SharePoint, can and do create elegant solutions for their needs. The issue is to pretend that these solutions are not useful unless they fall in some overarching top-down decision made by IT pros and consultants.

    This is the best selling point for SharePoint, not that it enables chaos, but it enables the user base to solve their problems, WITHOUT some SME interference.

    If we're using off the wall analogies, SharePoint might be like telling your kids to put their toys away. I'd rather have them stick it in the toybox(SharePoint) than hide it wherever they want(no solution at all, lots of different solutions, etc…)

  8. MN,

    I've answered, or at least elaborated, a bit on point 2 in the community responses meta post:
    http://furuknap.blogspot.com/2009/10/sharepoint-sucks-and-heres-why.html

    I'm not saying users are stupid, only that the freedom comes with a price, one that is not marketed by Microsoft or anyone else as a strong selling point ("Give your users absolute freedom and you need to hire five certified admins to keep the site running" isn't exactly marketing material)

    You need to balance the cost of maintaining a solution, not just solving the immediate needs but also what will be useable in three years or in five years.

    Full freedom is just a webified implementation of the 'one employee – one spreadsheet' policy. How to you ensure data integrity or reusability? How do you retain knowledge from all those sites? These are questions that are rarely answered when someone dives head first into setting up SharePoint and just letting go.

    .b

  9. I agree that Sharepoint sucks. Here is why:

    1) Companies are promised a lot more than they get, because they do not comprehend the huge task it is to get a Sharepoint solution working in their organization. I also agree that this apply to many platforms / software solutions, but still; Microsoft is pushing this as if it is the solution to everything.

    Then the day comes.. the mangager(s) has decided to buy Sharepoint.. And the developers are told to make the fantastic solutions…

    Developing in Sharepoint is like swimming in a burning river, with your arms and legs tied to heavy rocks!

    It is correct that you get a framwork taking care of security (integration with AD), menu system, "document handling", the abillity where users can create their own lists etc… but that is as far as it goes..

    You can make code using e.g. Visual Studio, or free versions of VB.NET or C# Express. You can hook dll's up, and assign classes to a list, and an event in a list (e.g. before upate, updating etc.).

    How do you debug? Well.. you have to have e.g. Visual Studio installed on the same machine as Sharepoint!! If you debug, only one person can debug towards the same machine at a time!!!!

    You can buy lot's of nice plugins, to get around limitations…but for what cost?

    When you get to the point of deployment, you'r up for a surprice.. I have never (working with it since early 90's), worked towards a system where publishing and updating is more hopless. Stuff that takes 10 min in e.g. aps.net or WinForms, takes hours / days in Sharepoint (if you do not belive me, just try…)

    If you are doing more than setting up a small site with 10+ persons (a site is web collection of web pages with some detached information and file storage), you'r better of developing from scratch!

    Search and find a framework somewhere else, or build everything by yourself..

    If you look at all the good stuff in Sharepoint (because there are some..like sync. with Outlook etc), and compare it with the bad stuff, you should get a huge pay raise and become the companies most valuable person, if you manage to say not to Sharepoint and yes to another option.

    DO NOT USE SHAREPOINT for application development! Sharepoint is a glorfied version of your shared company drive. It is not relational, and creating reports or any logic that rely on a structured system, is so complex that you will shake your head and cry if you are trying to do this towards Sharepoint..

    To bad M$ did not do a good job when developing Sharepoing, it could have become something good…

  10. SharePoint is the biggest load of c*** I've seen in years… Most of the time, "SharePoint" is really a buzz word to marketing/BDMs who don't know better…

  11. True Story.

    Customer wanted Sharepoint, and especially Sharepoint 2010. Migrating 50 Lotus Notes Applications.

    Solution looked semi feasible because people involved in the decision making were not developers but project managers and product owners, who know very little about SharePoint.

    We’re now about 6 months behind schedule. Some of these application were supposed to be “easy”, yeah right, with SharePoint nothing is easy.

    I got stuck on a Taxonomy solution. Referring to your part-1 post, what do you get with SharePoint but poor quality 1/2 implemented solutions.

    Anyone who has worked with SharePoint Taxonomy in earnest will realise it isn’t fit to be called a product. It would better be described as an alpha prototype. Ridden with bugs, some very hard to trace, and the only way you can get these solved is my opening up Microsoft Gold Support tickets (at your own cost)., and work with Microsoft (at your own cost).

    The Taxonomy solution I developed over 4 months, has proven to be so unreliable, that it is likely we will have to throw it out, and look for another solution.

    In the meantime the customer is not happy with the rest of the proposed solution because the functionality is far worse than what they had in “outdated” Lotus Notes.

    Do I think SharePoint sucks? I’ve been a developer for over 10 years, working on many differant frameworks, languages, reporting tools, and a few platforms, but in my 10 years, I’ve never come across anything as bad as SharePoint.

  12. Am I the only person who thinks SP is half-baked and always will be? It’s never going to be “finished” but then, neither is the hardware industry. Communication and information technology is mercurial. It will never end because geeks need cash.

    Jus’ sayin’ …

Leave a Reply

Your email address will not be published.