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.
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!