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]> You can also hook up on twitter (@furuknap) and let me know how you feel there.


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

SharePoint Sucks – And Here’s Why – Part 1

My good friend Bill Simser recently wrote about why he thinks SharePoint is great. Actually, he didn’t say SharePoint is great, he’s trying to explain why SharePoint does so much more than whatever people compare it to and why apples and gasoline should not be compared.

I’ll say what really on his mind: SharePoint sucks. SharePoint sucks at blogging, compared to blogging tools. SharePoint sucks at document management, compared to dedicated document management tools. SharePoint sucks at web content management compared to pure web content management tools. You’re basically getting mediocrity in everything.

Oh, and before you wonder, this is not another of those 8 Reasons Why SharePoint is Bad for Your Business, sarcastic posts. Really, I think SharePoint sucks.

Bill argues that, while SharePoint may not stand up to any dedicated tool, you get all the other features in the same bundle. For some reason, it makes perfect sense to Bill that if you’re looking for a blogging platform, you should consider whether you want a wiki solution at the same time, or even later. Or some of the other features that SharePoint provides.

My problem with this is simple: If I want a good blogging solution, why would I want a mediocre wiki site, a mediocre document management solution, and a mediocre web content management solution, bundled with a mediocre blogging solution? This won’t give me anything I need, compared to getting a good blogging solution and a good wiki solution as separate products.

Ah, but as we all know, SharePoint isn’t a product; it’s a platform. You shouldn’t take what’s given out-of-the-box and use as your production solution, with a few exceptions, such as Billy’s example of small and simple collaboration needs. Rather, you should take what you get as a starting point and then customize or develop the functionality you need beyond that.

Now again, I ask: if I’m going to customize a blogging solution in any case, why would I choose a mediocre starting point for my customization? I could start with WordPress and hire some offshore developer to customize whatever I need. You’ll save tons of time and money and you’ll get, in the case of WordPress, a flora of free addons and plugins that make the SharePoint addon community look like a fart in a hurricane.

Let’s put this in perspective, since Bill likes the apples and gasoline comparison. If you want to buy an apple, you’ll get half an apple with SharePoint. Or, more precisely, you’ll get a bad apple that either doesn’t taste good, look good or doesn’t have the nutritional value you seek.

However, you’ll also get a three-piece suit made of low-quality fabric that doesn’t stand up to rain. And, to make the offer even better, you’ll get a screwdriver made of rubber, useful for screws and bolts that are not really fastened. You’ll also get a paper bag to put all your stuff in; of course, it’s one of those fold-it-yourself bags and the instructions are not really telling you enough to put it together. As for the gasoline? You’ll get diesel. Very useful if your car runs on diesel – not so much if it’s not.

Still, all you really needed was a good apple.

So, yes, I think SharePoint sucks, and if you are considering going for a new platform for your collaboration or your publishing or your wiki or your blogging needs, choose differently.

Read the second part of this series to learn some of the specific things I hate about SharePoint.


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

Building Your First SharePoint 2010 Application

If you are a member of the Office 2010 Technical Preview program, you have all you need to write your first SharePoint 2010 application.

How? Well, the Office 2010 integration with SharePoint 2010 means that you’ll get a few interesting DLL files added to your Office installation folder, especially when installing SharePoint Designer 2010 and Visio 2010.

BTW, this information was first published in issue 2 of the SharePoint 2010 Beta series of Understanding SharePoint Journal.

Figure 3

These files are proxy DLLs and wont actually interact with SharePoint, but they are still extremely interesting from a developer’s point of view as they are effectively a complete listing of the new Microsoft.SharePoint.Client namespace.

This will be an extremely simple demo, and you’ll need to have the SharePoint Designer 2010 Technical Previews installed. Well, actually, you’ll need a DLL that installs as part of that application, Microsoft.SharePoint.Client.Local.dll.

Start a new Visual Studio project; any version of Visual Studio will do. The project type should be Console Application, and you can name it pretty much anything you like.

Next, add a reference to the Microsoft.SharePoint.Client.Local.dll file, usually located in the C:\Program Files\Microsoft Office\Office14 folder (or the equivalent in an x64 OS).

Inside the Program.cs file, add a using Microsoft.SharePoint.Client; statement at the top, and then paste the following code in the Main function:

foreach (int s in Enum.GetValues(typeof(ListTemplateType)))
          Enum.GetName(typeof(ListTemplateType), s), s

Build, run, and enjoy the output, which should resemble the result below.

Figure 5

Here’s the list in text format, with the new list times highlighted:

NoListTemplate 0
GenericList 100
DocumentLibrary 101
Survey 102
Links 103
Announcements 104
Contacts 105
Events 106
Tasks 107
DiscussionBoard 108
PictureLibrary 109
DataSources 110
WebTemplateCatalog 111
UserInformation 112
WebPartCatalog 113
ListTemplateCatalog 114
XMLForm 115
MasterPageCatalog 116
NoCodeWorkflows 117
WorkflowProcess 118
WebPageLibrary 119
CustomGrid 120
SolutionCatalog 121
NoCodePublic 122
ThemeCatalog 123
DataConnectionLibrary 130
WorkflowHistory 140
GanttTasks 150
Meetings 200
Agenda 201
MeetingUser 202
Decision 204
MeetingObjective 207
TextBox 210
ThingsToBring 211
HomePageLibrary 212
Posts 301
Comments 302
Categories 303
Facility 402
Whereabouts 403
CallTrack 404
Circulation 405
Timecard 420
Holidays 421
IMEDic 499
AssetLibrary 851
IssueTracking 1100
AdminTasks 1200
HealthRules 1220
HealthReports 1221
InvalidType -1

Using .NET Reflector you can open any of these DLLs to start exploring the SharePoint 2010 object model right now.


Pin It