SharePoint Sucks – And Here’s Why – Part 3

As promised, here’s the third installment of my reasoning of why I think SharePoint sucks. I’ve written two posts already, and if you land on this post, you may want to check out the previous posts first.

In the first post of this series, I nagged about how Bill Simser marketed SharePoint as a mediocre solution to a whole range of problems, arguing that if you settle for a mediocre blogging platform, you’ll get a mediocre wiki solution free of charge.

In the previous post of this series, I mentioned a few reasons why I think SharePoint sucks. However, and as several people noticed, only one of the items were really technically about SharePoint. The remaining posts were about how SharePoint was marketed both by Microsoft and the SharePoint fauna.

I also wrote a meta post to answer some of the community comments. Since then, more blog comments have been posted, and likely some that I’ve not found as well.

So, in this article, I thought I’d mention more reasons why SharePoint sucks, why it’s a faulty product, and why Microsoft had better be darn impressive with their next version, SharePoint 2010, soon to be available as public beta.

Code Quality

If you’ve ever tried to reflect the SharePoint DLLs, you may have encountered rather curious constructs. Here’s an example from SPList and it’s HasExternalEmailHandler property:

internal bool HasExternalEmailHandler
        bool flag = false;
        using (IEnumerator enumerator = this.EventReceivers.GetEnumerator())
            while (enumerator.MoveNext())
                SPEventReceiverDefinition current = (SPEventReceiverDefinition) enumerator.Current;
                if (current.Type == SPEventReceiverType.EmailReceived)
                    goto Label_0037;
            return flag;
            flag = true;
            goto Label_002D;

This is actually one of the easier examples to understand; you’ll find plenty of goto constructs and variable naming that will leave you crying for mercy if you try to figure out what’s going on. The fact that it all works is probably a bigger mystery than Loch Ness.


How can, by the deities, any product be recommended as a front end for public web pages when anyone able to append _layouts/importpolicy.aspx to a URL can take down the entire installation? SharePoint security and permission handling is a nightmare, and as I’ve previously written, anyone looking to use SharePoint as a web front end had better

  1. get their heads examined
  2. hire some seriously skilled security people
  3. prepare for some serious stability and security issuesor, more often than anything else
  4. fire their advisors who put them up with SharePoint as a web content management solution in the first place

Even Microsoft aren’t able to secure their own SharePoint sites, as I wrote in the web front end article, with presumably the best people in the world of SharePoint working for them. They use a custom solution to prevent anonymous users from seeing their innermost secrets. However, if you have a Live ID you can still see the SharePoint interface of their site (update: this has since changed and Microsoft has implemented SharePoint 2010 which doesn’t have this particular vulnerability).

A solution, by the way, is dead simple, so there really isn’t any reason why it’s not included in the default SharePoint installation. Instead, hundreds of public facing SharePoint sites are open and inviting to anyone with a large enough document management policy.

The permissions model is also a chapter of its own. By use of a very intricate model, SharePoint renders practical use of item level permissions almost impossible, again requiring users and customers to either limit their requirements or suffer performance and manageability issues.


I’m sure someone, somewhere, knows what went wrong the day that CAML was invented. Was the gods unhappy? Did the person who came up with the idea want to get back at their employer for something?

I want to add a single column to a single view. Just do display something as simple as a single line of text. Let’s see what it takes in, for example, the most basic of lists, the Custom List. In the screenshot below, I have closed the two views that are responsible for displaying the Title column, and only the Title column, of a custom list:

Figure 1

Notice the line numbers? The default view, the one that a List View Web Part uses to display a list, is 1016 lines long. The All Items view, used to list the single Title column in the AllItems.aspx view, is 1130 lines.

No wonder people fear writing custom views more than they fear death, cancer, or Marilyn Manson.

Are You Done Yet?

Hell no! I’ve got more coming. I could go on like this for volumes. I could talk about documentation. Development tools. HTML Compliance, or the possibility of making SharePoint compliant. Or a number of other topics. Not because I know secrets that are not known, but because SharePoint truly sucks.

However, in the next part I’m going to share with you some secrets that may explain why I’m still so fascinated by SharePoint, and why I’m still spending most of my waking hours thinking, writing, or talking about SharePoint.

And it’s partly your fault…


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

Why I Prefer SPTechCon over SPC

With all the buzz about the Microsoft SharePoint Conference this year, especially with the launch of SharePoint 2010, you may think that this would be a prime arena for someone like me to attend. It’s the premier event for SP2010, it’s the launch of a new era, everyone will be there, etc.

I’m not going. I could have gone if I wanted, but I explicitly told my boss that I’d resign if he sent me.

Let’s kill one myth right way: You just have to be there.

No, I don’t. The online coverage of the event is brilliant, with the team doing live blogging, live broadcasts, live tweeting, and pretty much anything else you can put after live. When you’re stuck in a session in Vegas, I’ll be monitoring all the sessions at once, switching back and forth by the flick of an ALT+Tab. I’ll be able to view pretty much everything, regardless of my physical location. In fact, being there is likely going to be less informative than having decent filters on Twitter.

Do I get any earlier access to inside material if I’m there? No, I don’t. Well, perhaps a few hours, but then again, those aren’t the hours that will make or break my next year of SharePoint work. It may make sense for someone who wants to blog about the newest and coolest features, but frankly, I’m going to stay off blogging the first few days after SPC. Anything posted would be drowning in the mouth-diarrhea that the MVPs will suffer when they’re finally allowed to say SP2010 without clearing it with Dave Pae.

I’ve written pretty much everything I want about SharePoint 2010 already, since I’ve had non-NDA access to the bits for several weeks, so I’m in no rush to get anything out. right now, I’m content with exploring SharePoint Designer 2010 workflows for an upcoming USPJ issue, and dive into all the cool tricks that the old dog has learned.

So no cool information either, and no early-bird blog posting.

So what about the social aspect? Actually, that’s exactly why I wont be going. Everyone will be there. I’m scared to learn that over 7,000 people are attending. Well, I’m not scared of 7,000 people, I’m scared of wasting three days, plus travel across the globe, to be in a group about as personal as walking down a random street in a large city.

There are, perhaps, 10 people I’d travel around the world to meet, and chances are, you are also going to want to meet those 10 people.  Can you imagine 7,000 people wanting to shake hands with Joel Oleson? He wouldn’t have time to spell his name, let alone talk to you in any meaningful manner. It’s just too much at once.

So, I prefer smaller and more personal conferences. I had the great privilege of speaking at SPTechCon in San Francisco earlier this year and I must say, I absolutely loved it. I met a lot of nice people, and everyone seemed to have time. True, they were rushing between the sessions, but the breaks were calmer, the reception was… I wouldn’t say intimate, but at least it wasn’t 7,000 people rushing over to Nintex to get their SWAG.

Here’s my advice, in the odd chance that you’re anything like me. Stay away from huge, monumental events like SPC, and stick with the less crowded conferences. Chances are, you’ll not only have time to talk to the speakers, but they’ll have time to talk to you too, and that kind of social event is a lot more valuable than being an ant in the anthill of SharePoint.

I haven’t had the chance to go to any SharePoint Saturdays yet. However, from what I’ve heard from the people who attend, there is a distinct difference from juggernaut conferences like SPC. No, it’s not in the amount of SWAG, nor in the people attending (you’ll often meet the same gurus at SharePoint Saturday as you would on SPC). The difference is in the feeling everyone has of being part of an event, not just being there.

Oh, yeah, and I’m definitely going to SPTechCon in February. Hope to see you there, and I will have time to talk to you 🙂


Pin It

SharePoint Sucks – And Here’s Why – Community Responses

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.

I’m somewhat surprised at the responses to the SharePoint Sucks series that I’ve been running. My first surprise was that this didn’t spark a flame war. Although that was not my intention, I had expected people to fire up and call me names my mother shouldn’t hear.

My second surprise was that most of the comments I got agreed, more or less, with the statements I made. Most of the comments, emails, tweets, and offline discussions I’ve had have so far said that this makes perfect sense, even if many people don’t want to use the word suck.

However, keep your comments flowing. If you hate me, fine, let me know. If you agree, well, let me know that as well. And if you don’t care, just skip on over to some other topic that interests you.

I’ve gotten a couple of community responses that I think deserves a better response, so in this meta-post, I’m going to respond to those comments before I post the third part of this series.


Robin Meuré asked in a comment to the previous post what would be the alternative to letting users have the freedom to create their own solutions.

I don’t think there are general recommendations that can be applied to just any situation. Would you allow users to express their creativity with the company web site? How about the accounting system? Just add a few workflows to skip the payouts to managers is creative enough that you’d be thrown in the brig for years.

In a wiki site, of course users should express their creativity in adding and updating content. Does that mean they should express their creativity in modifying master pages so that your solution no longer follows company guidelines?

Even from a technical point of view, users can kill a SharePoint server very easily, for example through custom workflows in SharePoint Designer. So, you’re back to having to teach your users to design these in a safe manner, and suddenly it’s not that easy or cheap after all.

My point is that users are not competent enough to be given the freedom that SharePoint can provide. They need to learn a lot about application architecture, functional logic, be updated on company policy, learn about usability standards, and a lot of other topics.

Again, I want to point out, as I did in the previous post, that creating business solutions is not for the faint of heart, and the requirements for understanding both the business and the technical logic haven’t decreased even if the entry point is far lower than it used to be. If you want to empower your users to create their own business logic, you’d better tell them that it will take a whole lot of precautions, architecting, and development if they plan on maintaining a useable environment.

SharePoint gives the users freedom to cause even more havoc than they already can. Either bolt everything down or let go; it’s up to you, but it’s probably a more difficult choice than most people are aware.

Show Me Something Better!

Several comments, and I’m not going to single out any individual here, argues that SharePoint is the best there is, and that if I am to say that SharePoint sucks, I also need to give a better alternative.

Sure! Minesweeper is a better alternative. To be more precise, Minesweeper is better than SharePoint if your requirements are to have a good time for 5 minutes. Now, you’ll probably say that I’m talking rubbish, since it’s a stupid comparison, and you’d be correct. I may not be able to tell you which alternative is better without knowing the requirements.

However, the fact that perhaps no other alternative is better at exactly what SharePoint does means nothing. A serious sunburn is preferable to losing a limb or a heart attack, but it’s still not good.

So no, I’m not going to give you an alternative that’s better than SharePoint at what SharePoint does, because the question is constructed so that SharePoint would always be the best alternative.

Am I Lying?

Dave McMahon, one of the newly appointed MVPs, and congratulations and good luck with that, wrote a response in his blog that he doesn’t think SharePoint sucks and why he thinks I don’t think SharePoint sucks. If he were correct, however, it would make me a liar. I do think SharePoint sucks.

Dave points out that, compared to starting an ASP.NET application from scratch, SharePoint will save you tons of time, because it already has a lot of features for content management, collaboration, publishing, Office and workflow integration, etc.

However, why compare to starting an ASP.NET application from scratch? Of course it’s better than starting from scratch. Heck, if you need a word processor, SharePoint will save you tons of time compared starting with a blank class library and building your own. That doesn’t make SharePoint a good word processor.

Compare apples to apples, and SharePoint to competing products. Comparing SharePoint to junk and saying SharePoint’s better doesn’t do anyone any good.

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.


Pin It