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:
- Far too complex to install, configure, and customize. It is not agile.
- 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.
- 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.
- 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
millionsbillions 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. - It's rendered HTML is brutal, along with the CSS files.
- +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.
- 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.
- It is one of the most unflexable applications I have ever used.
- 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).