Another SharePoint Sucks Post Released into the Wild

I'm in a quippy mood tonight and stumbled across a post titled "Why SharePoint Server is Terrible". Of course you know flame-bait like this just gets my blood boiling, especially since there are points here that are completely inaccurate and don't represent the peoples the author is talking about (like MVPs). A few months ago there were blog posts about how bad a development environment SharePoint is and for the most part I agreed with what was being said. It's not great, but it's better than hand coding the world yourself. Now we get this post that goes deep into why (as the author states it, not me) SharePoint is terrible and a failure.

I'm going to nitpick points here because overall the article is just plain negative on SharePoint. Like I said, in some cases SP blows monkey chunks. Yup, you heard it. A SharePoint MVP saying SharePoint bites. However take that with a grain of salt as it can create major suckage in some areas, it excels in others, so you have to balance what you read (even on this blog) with the context of reality and what business problem you're trying to solve. No technology in the world is going to solve problems, it's how you apply the tool or technology to aid you in a solution.

The author states that SharePoint is a great idea, but failed for three key reasons:

  1. Far too complex to install, configure, and customize.  It is not agile.
    1. Any particular reason why people associate "agile" with "complex"? I build enterprise systems that cater to thousands of users, written using TDD, built on top of SharePoint infrastructure, and follow agile principles but they're all complex systems IMHO.
  2. It is being sold as a solution to organize unorganized companies.  It is being sold as a system to add process's to organizations that don't have them.
    1. I'm making an assumption the author is one of these "unorganized companies". I for one (and most of my cohorts in crime) would never recommend a product if it didn't suit the needs of an organization. Installing SharePoint for the sake of installing it (because some CEO read a glossy brochure) is nothing about what SharePoint is or does. I for one don't make a dime on the millions billions that SharePoint has made for Microsoft but would never stand behind pushing the product into a place where it didn't belong. I've also never seen it sold by Microsoft to corporations that didn't need or even want it. Grant you, user adoption can be slow as it's IT that sometimes makes the decision to bring it in but I've never seen an IT organization bring in the product when they weren't ready for it, or didn't have an idea of how it fit into an already existing process. Processes don't fit tools, appropriate tools are adapted to support them.
  3. It's rendered HTML is brutal, along with the CSS files.
    1. +1 for the rendering of SharePoint pages which can be painful however it has got 10x better with 2007, Master Pages, and better support for ASP.NET. It's still a little brutal and can be cumbersome due to the large number of styles and classes in the CSS. Brutal rendering? Have you seen the HTML output from other portals (Oracle, PeachTree, etc.). I have and SharePoint is a walk in the park compared to them.
    2. SharePoint OOTB doesn't conform to W3C standards so if that's an issue you'll have to wait or do a lot of customization. Yeah, this sucks and is one of the biggest problems with SharePoint rendering but I don't consider it as a result of HTML vs SomethingElse. Just bad rendering by Microsoft.
  4. It is one of the most unflexable applications I have ever used.
    1. Unflexable? Is that even a word. Unflexible? Maybe inflexible? Inflexible is the inability to change. Considering that SharePoint is an extensible platform that I can build solutions on top of to deliver legal document systems, help desks, training portals, or drive the XBox public internet site I don't consider that even remotely close to "inability to change".

Okay, so that was 4 reasons not 3, but who's counting right?

The author goes on to state you have to be a master of many tools. I will admit that SharePoint encompasses a lot of tools and technologies, but I am far from a master in many and some I don't even use. Ever. So do you really have to be a master in everything below to harness SharePoint?

  • SharePoint
    • Redundant, see redundant. So to be a master in SharePoint I have to be a master in SharePoint? This makes total sense.
  • SQL Server
    • If you've ever read my blog, tried to access the database directly, or wrote me and asked me what the name of the sproc is to delete a revision of a document from SharePoint you'll know that my motto is "stay out of the database!". So other than setting up (i.e. installing) SQL Server I fail to see what anyone has to master. In any case, there are guys far smarter than I who can make SQL dance and sing. Let them deal with it.
  • Internet Information Server
    • Again, what must I master here? Install it and turn it on.
  • Active Directory
    • Why must you be a "master" in AD to make it easy to configure SharePoint? In every setup I've done (both virtual, development, production, and otherwise) you install and generally AD is known (as long as the server is part of the domain, well, duh) and it just works. True, I've had problems with say domain groups with "&" and other characters in the name, but being a "master" in AD might help in knowing SharePoint but then it might help in knowing anything connecting to AD (like say your desktop).
  • File Stores
    • With each point here, my brain just gets fuzzier and fuzzier. File stores? Master? SharePoint can index a file share. Point it at it and make sure the crawler account has the right priveledges and you're done.
  • Indexing
    • Indexing in SharePoint can be more of an art than a science, but for all but the largest of installations I've seen or done (meaning 100 million documents spread over 3 data centres), indexing was OOTB and pretty much a brain-dead exercise.
  • Software Development
    • You must be a master in Software Development in order to use SharePoint. If I said this at a conference, half the room would walk out (the half that didn't already walk out when my demos blew up). I mean seriously, "software development" is such a broad term. Yes, if you want to build web parts and solutions using SharePoint you'll need to know what you're doing, but that's true for most anything. Try doing brain surgery without training. It's a messy subject.
  • Search Engines (To help customize the brutal search built into it)
    • I think the search engine needs work and customizing it can be difficult, however again it's perception and what is crap to some is fine for others. I once had a client who said "make it more like google" because they didn't like the search. We changed the style sheet to look like a Google search page and apparently that fixed the "problem" they had with it. Go figure.
  • Database Design and Development
    • I have no idea what database design and development has to do with SharePoint? You don't "design" nor "develop" databases with SharePoint and if you are, then you're doing something wrong.
  • XML
    • Calling any web service requires some understanding of XML. I don't consider the XML coming out of SharePoint web services or the XML config files to be any more complex than anything else that uses XML.
  • .NET 2.0
    • Again, if you're doing development you'll need to know .NET to build web parts but for the majority of clients I work with, they just want a tool that works and don't want (or need) to invest the time/money/effort to build custom solutions with code. A lot can be done with templates, packages, features, and what you can leverage OOTB.
  • ISA Server
    • For front-end web servers knowledge about this is a must, but for the majority of clients SharePoint installs are internal and don't need this. Again, if you need an externally facing system you'll probably have someone that knows ISA.
  • Master Pages
    • Being a master of master pages does not help you with SharePoint. It merely lets you build dazzling looking websites (if you know what you're doing and have a little design savvy) for use with SharePoint.

I think not.

I just don't get the whole "Document Management Process" excuse. He basically goes on to say Microsoft is so busy with pushing their SharePoint crack they're ignore people who need to understand document management, and people miss the mark. Document Management, or better yet, Information Architecture, is bloody hard. It's not something you can sit down with 2 guys and a small dog and bang together in an hour (unless you really do have 2 guys and a small dog in which case your IA is probably 5 emails a day and 3 PDF files). It takes a lot of work to figure out taxonomies, best practices, placement, structural and organization change, and adoption. All of which completely hinge on your customer and how mature their understanding of their own information is. No tool on Earth is going to help you do this right as it's all contextual to the organization, so blaming SharePoint for this failure is just asinine.

Wiki's Rock. Uhh, yeah. I guess so. Grant you Wikipedia is pretty good and at least you can search for stuff. However wikis suffer from two major problems. First, you have to know what you're looking for before you go looking for it. Second, structurally they suck when trying to organize information in a sensible way. Substituting another tool (MediaWiki) for SharePoint to solve an information problem is missing the root cause of the issues. While it may look better in the short term, years from now when you have thousands (or millions) of Wiki pages and you're trying to discover something useful, you'll kick your IT guy in the head who came up with this flavor of the day.

The author makes a comparison to MediaWiki and BaseCamp. Again, I don't get it. BaseCamp is like an online project management tool (with some document management bolted on the side). True, it's highly customizable from the look and feel but at the core it's a mess and isn't extensible to do anything but what it was designed to do. And MediaWiki, well, it's a wiki. You create content. That's about it. If we want to compare apples to apples, let's talk about SharePoint vs PeachTree vs Oracle vs LiveLink.

What the author mentions isn't anything new. We've known it for years and it's a sore point for us working with SharePoint. However as with any technology, it's got it's growing pains and it's far from being done. We'll continue to learn, adapt, and make things better. Any software the size of SharePoint *is* inherently complex. The KISS principle doesn't apply across the entire system, but it can be applied (and is) in isolated parts of it where appropriate. A comment on the original blog about Photoshop is interesting. I don't go into Photoshop (much) and when I do it's for simple things (resizing an image) and an alien world. I consider myself a fairly bright guy who can pick up most anything, but PS is a crazy beast with all kinds of secrets of the underworld just waiting to be revealed. There are people on this planet that can make it sing and dance and stand on it's head. I am not one of these people. I however can so similar things with SharePoint so it's all complex, from a certain point of view.

As Bill English stated, this is a product with a huge install base and revenues of +billions. Yeah, billions of dollars are going into BillG's pocket (or maybe it's Ray now, I can't keep track of those two crazy kids) as a direct result of this product. That speaks volumes. Millions of documents and thousands of sites spread across multiple data centres housing most everything Microsoft does on a day to day business. That speaks volumes. The drive and demand we put on Microsoft to make the product bigger, better, and faster than it ever was (well, at least easier to work with, faster would be nice too... and works on Vista maybe?) is what we do and what people want, and there's demand for this. If it wasn't we wouldn't be asked to speak and continue to communicate and educate people about SharePoint and we would all be living in a WebSphere world wouldn't we?

I fail to see how this author can write this sort of post without having first hand experience with SharePoint (meaning setting it up in an enterprise environment, not just looking at the pretty pictures on the web or running a VM for a few minutes).


  • @SharePoint Is The Devil: First off, come out and tell us who you really are or are you afraid you'll get flak from others if they know who you are? Anyways, I did say that SharePoint is not without flaw. Never said it was the golden child or silver bullet some might think it to be. However anyone who pushes the wrong product into their organization and then blames the product for their failure shouldn't be in the position they're in for very long. If I pushed SharePoint on someone who didn't need/want it then walked away I would't be in the business very long. That was (one of) the points I was trying to make. It's not the fault of a product if people misuse it.

    As for the grammar attack, sure I'll admit that I was being nitpicky about it however the claim the original author made was that SharePoint was unable to change. I don't agree. There are dozens of sites that are built on SharePoint that bear no resemblance to the OOTB experience nor do they conform or are restricted to the way SharePoint does things, as the people implementing them have gone out of their way to customize and adapt it to their specific needs. SharePoint is software, not hardware so making a claim that it can't be changed to suit the needs of the user is just plain wrong. Can it be all things to all people? No way, but it can certainly do the job (for the most part, it's not perfect) that it needs to.

  • "Any particular reason why people associate 'agile' with 'complex'"?

    Sure, because "agile" is all about doing the simplest thing that could possibly work.

    That is, until you do the simplest thing that could possibly work and then the Agilists begin the game of three card monte and insist that testability, dependency injection, IoC, etc are most critical, and actually simpler than dragging a datagrid onto a form.

    Not bitter much...

  • @Eric: Brilliant post. I really enjoyed this section which should probably be minted in steel and used to beat people upside the head with at SharePoint conferences:

    "So here's a tip to those who haven't been hit by the clue train yet - SharePoint isn't going away. Think you're comfy writing one-off Java or .NET apps for a nice wage? Guess again, Gomer - your world is about to turn upside down. SharePoint is going to gate-crash your party in an armored Humvee and start pulling your beloved JAR files and delicate CGI scripts out by the roots."

    Hehe. Almost spilled my afternoon coffee over that.

  • Let me just say this, as primarily a BI guy who has become responsible for essentially a sharepoint frontend of reporting services. I have spent the better part of a week trying to migrate our current production environment to a different dev server with a fresh sharepoint install. I have run into more errors then I can count, and tried multiple sharepoint tools to try to accomplish this. I have posted multiple times to the Sharepoint MSDN message boards with not even a single response other than myself practically begging for some advice. For probably the first time in my life in IT I am looking at a situation where I have no clue how to successfully do what seems like a pretty typical task, and I see no hope in sight. Hence my frustration and typing in Sharepoint sucks into google just for fun, and I stumble upon this.

  • I've set up SharePoint in lots of medium to large scale enterprise environments. Setting it up is a terrible experience, developing for it is a terrible experience, and using it is an even more terrible experience.

    It's only when you've watched someone spend a full 10 minutes, with a look of abject misery on their face, attempt unsucessfully to locate a file or add a simple item to a calendar, that you realise just how bad SharePoint is. You can talk about your mossy pillars all you want, but the end user just doesn't care about any of that techno-babble, and I've yet to meet an one who enjoys using SharePoint. Hell, I've yet to find one who doesn't flat out hate it. I'm not going to bother comparing it to huge products such as Oracle, as everyone knows those products are just as fat and stupid as SharePoint is. However in probably 85% - 90% of the cases where I have installed it, it just wasn't neccassary in the slightest. It's crammed with a million features, but no-one uses virtually any of them. Most of the time it just ends up as a glorified file repository or calander, and that's the functionality that can be gotten or created for free or next to free very easily.

    As for the deployment we use internally, it is common knowledge that if you have a file that you don't ever want anyone to find, you just upload it SharePoint. I'm developing a solution to replace our requirement, which is pretty much just a file repository and a resource booking calendar.

    I've since managed to talk several companies out of buying the reams of servers and licences required to host all this bloatware, and they've ended up with nice small products that do everything they need. While this has meant that we've made less money from them, they've all been back for repeat business. No-one likes being sold stuff they just don't need.

    Just one other thing - it's not my aim to offend you or anyone else who has worked on SharePoint, it's really not. But for virtually all of the situations I've seen SharePoint deployed in, it was totally excessive, and usually causing more problems than it solved. I'm sure it's great for massive Fortune 100 companies, but for the other 99.99% there is just no need.

  • I agree totally with Octopoid.

    I have taken part in the development of three large customised Sharepoint solutions and I can only say that Sharepoint is a load of crap.
    Most of what you get OOTB can be developed in house with relatively little effort, but SP makes all customisation and development at least twice as slow and hard to deploy, hard to maintain, hard to operate, hard to log and fault find and generally a pain in the ass.

    I have extensive CMS and web development experience and I can only recommend that companies abstain from using this low worth platform

Comments have been disabled for this content.