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
12 comments:
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.
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.
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.
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
Sharepoint Sucks Because It Doesn't Work!
It's a buggy piece of junk sold to executives and forced upon IT.
Thank you, last anonymous, for that informative comment that I'm sure really sets Microsoft in its place.
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.
Robin,
I'm going to expand on your question in the third article in this series, as your question isn't easily answered in a single comment.
.b
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.
Previous anonymous,
Why don't you take a look at the community responses post I made, answering your exact complaint?
http://furuknap.blogspot.com/2009/10/sharepoint-sucks-and-heres-why.html
Oh, and by the way... Not sure you're entitled to tell me what I should post in my blog. You're welcome to post your own content in your own blog, but since you don't sa who you are, your complaints will go unnoticed.
.b
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...)
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
Post a Comment