I'm looking into using SharePoint (WSS 3.0, specifically) for the document library and discussion board functionalities.

I'd like to ask those of you who have experience in SP (MOSS or WSS, since we might upgrade in the future) for a list of the items that ticked you off or required a difficult workaround.

Here's one from me - I found when I implemented forms authentication that a lot of the built-in integration with Microsoft Office disappeared, and I was also unable to use explorer view.

+5  A: 

As long as you are in Internet Explorer, a lot of the built-in stuff will work flawlessly.

I think it's a great product but my only "complaint" is that when you try to customize the hell out of it, you need to learn the API properly before doing things right.

So beside the learning curves, I think that WSS 3.0 is great at what it is doing. If you need more than WSS, SharePoint's licence is not for the "Personal" user. Quite expensive.

you also need sharepoint designer licenses
Alexandre Brisebois
You dont need sharepoint designer, you can use notepad if you're hardcore :)
true, then again you may need to find new devs and integrators
Alexandre Brisebois
Note that SharePoint Designer is now free.
John Saunders
+13  A: 

If you try to customize the layout and color of the sharepoint websites this can be a nightmare.

I also found troubleshooting difficult. There are different logfiles to search for the error, and it's never clear where to look.

+3  A: 

Have to agree with the other answers; if you want to customize it, be prepared for a few headaches.

+8  A: 

Troubleshooting can be 'interesting'. A resource I've found useful is SharePoint Debugging and Logging Tips and Tricks. Also, this MSDN article, Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 contains some great info.

Mitch Wheat
Great links, Mitch!
+31  A: 

It's extremely Windows-centric. If you have any developers who like Firefox, or the Mac, or if you ever want to get those kind of developers, then Sharepoint will be a big problem. Also, its "wiki" is hardly a wiki at all: it's as if some marketing guy said, "I hear wikis are big, can we do that?", and they labeled an HTML editor "wiki".

In general, Sharepoint is good if you are a completely Windows shop, and like looking at documents as if they were stored on your disk (folder-heavy, list views). If you want to experience information management the way the rest of the software community does, Sharepoint will be a hindrance.

Ned Batchelder
+1 the Sharepoint wiki truly sucks
Chris Ballance
+1 Good point: "wiki" is not a wiki, it is an "HTML editor". Once formatting mistakes are made they are difficult to remove. Very poor.
All the default List types that one can create are not meant to be best of bread. If you want a wiki, buy a good wiki platform. If you want a blog, run a linux server with a wordpress install. Dont try to cram everything in MOSS.
+28  A: 

I'm not even sure where to start:

  • Deeply confusing navigation structure - directories expand in at least two different ways
  • Differing views of the same documents - some of which don't provide editability
  • Nonsensical user-interface - to edit documents you must click on an "edit in ..." link which is a drop-down which doesn't even appear until you put the mouse over the (initially invisible) link
  • Very poor performance (in our installation) - loading / saving docs takes ages
  • No real version control - there doesn't appear to be a way to get back deleted documents, for instance (in our version; may be an administrator option)
  • Search which is both poor and confusing - seems to only give options to search either this "web" (whatever that is) only or every document in the entire universe (including stuff owned by finance, marketing etc) - and doesn't usually find what I'm looking for anyway.
  • No facility to edit documents offline - if you are editing a document and go offline (say take your laptop out of the office with unsaved changes), the only option is to manually save it to a location on your local drive then remember to copy it back in later.
  • No facility to bulk download documents for offline reading (but actually can be worked-around using the partially documented DAV interface)
  • Doesn't appear to understand how to edit MSOffice 2007 format documents (but this can be worked-around with DAV)

As we are forced to use this for documentation over the previous system, CVS, which was vastly superior in every respect (despite CVS's own problems), I find all of these extremely annoying.

"there doesn't appear to be a way to get back deleted documents" - Check the Recycle Bin. There are two: One for each Site, and one at the root of the Site Collection. Requires Permissions though.
Michael Stum
IMO, some of these are configuration issues that could be solved with some training and administrative attention. Of course the necessity for that effort for some fairly basic functions is a problem itself.
+1 for "Nonsensical user interface". Wish I could +10 that.
We haven't seen the problems with search. We've created separate scopes to either aggregate or segregate different content sources. Maybe things are better since the addition of Search Server 2008 to the Sharepoint package.
Kelly French
+2  A: 

I'd also like to voice my displeasure at trying to customise the stylesheets etc.

We use Sharepoint as our development wiki and trying to skin this involved extreme hackery.

Also not being able to replace the "HTML" editor (and I use the phrase loosely as it is a memo) in the wiki is frustrating.

+81  A: 

As this is a Developers Site, let's talk development:

  • Insane Development Requirements: You must have a Windows 2003/2008 Server as your Workstation, you really should be local Administrator on it. (Yes, there is a Workaround to Install Sharepoint on Vista, but that's not officially supported. And no, I do not consider "Develop on a Workstation and Upload your code to the test server" an alternative.)
  • SPWeb/SPSite.Dispose - You usually dispose, except if you don't. And if you dispose when you should not, bad things happen. Unfortunately, it is not really clear when to dispose and when not, there are a variety of Edge-Cases
  • Debugging/Error Logging. No comment on that, i'm too busy walking through the logfile to write my complaints in detail
  • Solution Deployment. The Creation of the .xml Files is not really well documented and .ddf Files feel like it's 1993.
  • Documentation, or more the lack of. What does SPSchedule.EndMinute actually DO? Will it forcefully end a running job? Most of the MSDN Documentation is incomplete or plain unhelpful.
  • CAML. ARGH! Look at this example of a simple CAML-OR Query. This abomination of "SQL for Sharepoint" is complicated, unintuitive, error-prone, and if you are doing it wrong, you get helpful error messages like "Cannot complete this action"

And one not development related issue:

  • Backup/Restore. Try backing up the entire farm, including the Configuration Database. Ok, backing up is easy. Now, try to restore it...

Microsoft calls Sharepoint "A maturing Product", which essentially means: It does do a LOT of things really well on the end-user side, but on the Developer and Sysadmin side, I think I have thrown more profanity at Microsoft than on any other company in history... And given the fact that Sharepoint is so expensive, I had expected a bit more from a product that first launched in 2001...

But overall, I think I'm happy with it, because as long as you use Internet Explorer and Office 2007, it offers a really neat and tight integration.

Michael Stum
Right on! All this above is true.
Pascal Paradis
You can just as easily run Server in a VM - done properly, you can share this VM across all members of your development team.
Greg Hurlman
The Problem with that is when you want to attach the Debugger to w3wp.exe and therefore block all other members of the team. Except the guy who is running a deployment script that recycles the app pool, therefore killing off your debug session... it works, but I would not recommend it.
Michael Stum
"It does do a LOT of things really well on the end-user side" Our end users would dispute this. They hate Sharepoint with a passion as it is ridiculously hard to navigate and makes no sense to them at all.
That's partially the Administrators task though - proper Navigation and building pages to customize the look'n'feel is a must. But if you have users that do not rely on Microsoft Office, Sharepoint may not make sense. But yes, I've seen better user interfaces.
Michael Stum
@greg - what are the license constraints on that scenario? One license per developer?
if you have MSDN your license issues would be solved for development.
Matthew Whited
Disclosure: I work on the SharePoint team at Microsoft In 2010 we've done a lot to address some of these complaints. 1. you can develop on Win7 2. big improvements to solution / Feature infrastructure 3. considerably more and better documentation // we heard about this loud and clear ;-) 4. way better VS integration 5. better methods to access data (REST etc) 6. considerable investment in backup/restore 7. FF/Safari are tier-1 browsers . I'd urge you to check out the Beta, available for public download. Feel free to email me with questions: [email protected]
Kevin Davis
I can't agree about #3 yet (still trying to find out how to programmatically access tagging), but overall, SP2010 seems like a worthy upgrade that irons out or at least improves on most of the really annoying parts of 2007.
Michael Stum
Works on windows 7 too.
+18  A: 

SharePoint is a big server product, but it is marketed like a tool you can just install and use.

It really requires people to manage it who really know the system and more than one person.

It needs informed server/hardware management to make sure that it is installed correctly and the underlying server and databases will run correctly.

It requires people who know SharePoint well so they will be able to avoid the pain described by people here (and elsewhere), not only for customising the look and feel, but even simple seeming customisations to functionality can end up being complicated.

On top of that, there are still very few people available with the knowledge of the product.

The upshot is that any first time install is going to have problems while people learn "SharePoint". Plan for server rebuilds and lots of learning time on your project , (then double it)?.

The discussion boards are rubbish. The community kit for sharepoint has an improved install for Discussion boards and I would reccomend installing this and evaluating against requirements.

The document storage of SharePoint is great, but there is some serious work needed to do outside of SharePoint in the management of document growth and organisation or SharePoint will rapidly devolve into a massive cluster f&*%.

Have you looked at They do some interesting work with the UI.
David Robbins
Whenever a project here involves SP, which is often, we bring in consultants that specialize in SP solutions. You can imagine how much that costs. I think it's for the reasons you mentioned - it requires a team of people that have a deep understanding of how the product works, and those people are hard to come across.edit: I'm only an intern here, so I could be wrong, but that's how it appears to me.
+6  A: 

It really requires people to manage it who really know the system and more than one person.

It requires people who know SharePoint well so they will be able to avoid the pain described by people here (and elsewhere), not only for customising the look and feel, but even simple seeming customisations to functionality can end up being complicated.

Nat brings up great points which need to be heard by many.

I've found that the best way to deploy an application in sharepoint is to adapt sharepoint to your needs and not to adapt your application to sharepoint. The second will lead to headaches and customization difficulties.

Alexandre Brisebois
+3  A: 

besides the already mentioned complaints the multilanguage / i18n support is not great. At least the german translation is crap and websites (SPWebs) with more than one language are simply not envisioned.

+4  A: 

They use tables all over for layout, but not consistently. The 508 accessibility is not good.

To add to that: At one point, their nesting is 18 Levels deep.
Michael Stum
18 levels? That's insane!
+17  A: 

Late to the party here, but one small, simple thing that makes life with Sharepoint harder is the fact that Microsoft have decided to use terminology for things in Sharepoint based on really common words that mean other things in the rest of the world. So for example, if you want to create a custom add-on for Sharepoint it is a "Feature", forms and customised list entries are "Content Types" and so on. Once you get your head around it that's not too bad when you're working with Sharepoint, but the minute you need to put it into google, searching for "features" or "content types" is going to get you loads of stuff that has nothing to do with Sharepoint and quite possibly a bunch of stuff that is to do with Sharepoint but isn't to do with the context you are looking for.

I'm sure they were trying to be user friendly with that, and for some kinds of user maybe they succeed, but for anybody who ever needs to use a search engine it's a pretty irritating fail.

EDIT: And another thing: Why are the form elements mostly given guids for names? That is really annoying if you need to add any extra Javascript for whatever reason...

Ah yes, terminology in Sharepoint is horrible. There are Features - but also Solutions. There is SPSite - which is a Site collection and SPWeb, which is a site. The Object Model is horrible in it's terminology.
Michael Stum
+1 Far too many things in Sharepoint are identified by only a GUID
Chris Ballance
+1 very true, so true - lots of blog posts, have to explicitly define things like - how to insert this thing... with code...
+2  A: 

My first real exposure to Sharepoint was in a training session at a Microsoft building. Having did a view source and seeing nested tables to the nth power, I later tried to be diplomatic in asking one of the Microsoft employees, "How is it for disabilities?"

"If you mean like screen readers, it SUCKS" was his answer.

Sharepoint has incredible capabilities, though. Oh, wait, I mean it's documentation promises incredible capabilities.

I'd be much happier with only half of the features if they all actually worked.

+8  A: 

The overriding problem is that Microsoft seemed to care more about the marketing of SharePoint that it's use. They knew they couldn't make SharePoint do everything well so they decided to make it do everything 1/2 assed. Wikis, Blogs, Language support with variations sound great - until you actually try to use them.

Alot of things are just too buggy or simply don’t work well enough out of the box. To get a content query web part to recognize a list of links, I have to export it to my machine, change some property I can only see in the xml, re-import it and drag it onto the page? SharePoint is complicated enough and already destined for complexity, but because it was shipped before it was QAed in any kind of real use scenario it's far too easy to just explode into a useless mess.

Another overriding problem with SharePoint is getting data out of it. To aggregate data from SharePoint sites I either have to use a bizarre xslt model with content query web parts or list my sources individually with an kludgey data view web part. The architecture around content types is great, if they are actually implemented properly, but I wish I could use that data more easily. Starting to think that maybe I should auto generate sql views on the backend...

Of course the development model. I have to develop on a server? Really?

I just wish Microsoft would have focused more on the core of the product, QAed it properly, and given everyone a solid foundation to work on with good documentation. Maybe they could have partnered with 3rd parties to get all the little bells an whistles in this version if they felt they had to. I sincerely hope that MS does not continue to plop on use-less features in the next version and instead tries to firm up the foundation. It's not just the product that suffers, it's the legecy of messy implemenation that get created.

SharePoint is very promising and I hope it does become the shinning hub of Microsofts app platform, but It will have to become alot clearer and cleaner before it does.

+11  A: 

Dealing with Sharepoint since STS days and the following have been gotchas for us:

  • Really meant for the entire MS suite, doesn't like Firefox, Unix/Linux users. There are "equivalent" ways of doing things for those folks but it's a different experience.
  • New features such as Blogs and Wikis are not that flexible. Try placing a Wiki entry on your parent site homepage.
  • You will require considerable support, and not just backup/restore the server if it breaks. The MS tutorials are not great so be prepared to answer calls at any time.
  • If you've turned off anon access at the server level, simple features like RSS feeds require a login. Fine if you use something that passes your credentials automatically, not fine if you use aggregators that do not.
  • Upgrades have not been seamless. i.e. Moving from ver 1 to 2, and 2 to 3 had untold issues with customisations. There's no evidence that this will change for future releases.
  • Their out-of-the-box XML web part requires you to specify an XSLT file. If you want a plain ol' RSS reader, you'll have to install a third party reader such as SmilingGoats.
  • If you want to be adventurous and leverage Sharepoint through programming, then it's develop on a server or use Sharepoint's web services. While I'm unfamiliar with the former, the latter requires an intense love for GUIDs.

Perhaps most importantly: If you don't put some structure to your site(s) up front, and guidance for your users then anarchy rules. Files can end up anywhere and in any site. Compound this with the ability to create sites from Office, meeting workspaces from Outlook and soon you have a site map from hell. And Sharepoint can't generate a decent site map so you've no idea how bad things are getting.

Still, if you're in a corp environment and want to move up the food chain, you can do far worse than get involved with Sharepoint.

Hedley Lamarr
"Upgrades have not been seamless. i.e. Moving from ver 1 to 2, and 2 to 3 had untold issues with customisations. There's no evidence that this will change for future releases."Thats not actually true. Microsoft have acknowledged this many times over and committed to improving the upgrade path significantly for SP 2010.
Acknowledging is one thing, doing is another. Then there's "doing" things the way Microsoft thinks it should be done and "doing" things the way the customers want. Not bashing MS, and I am hopeful, especially for the increased integration with VS for 2010. Time will tell.
Hedley Lamarr
+13  A: 

Like others have said, the development experience is a complete nightmare. Expect any development to take 3 times as long as similar ASP.NET dev.

That being said, I think it works well for information storage in a corp environment. Unfortunately, my experience is that no one ever wants to use it just for that. In fact, most people expect it to be like developing for any regular ASP.NET site and will ask developers to make it do crazy things it was never intended for (and the MS marketing team seems to push this too, which doesn't help).

Agreed. Its mainly due to developing applications which do not or should not be developed in SharePoint. Quite often the desire to develop a solution in SharePoint overtakes any thought for whether it is the right platform. Developing SharePoint solutions to appropriate business solutions can be painful, but it is a great deal faster than developing these in ASP.Net from scratch IMHO.
+2  A: 


I'm not an anti-Microsoft guy, but really I think that "Microsoft" in this case sums it up for me. If you're going to use Sharepoint, then you're locked in to the Microsoft way. You'll be running a Windows Server, accessing it with Internet Explorer and Microsoft Office, and developing with Microsoft-specific non-free tools.

For a "portal" type solution, I would prefer to work on something that is sensibly managed using standard, widely available tools (and have a wide choice of tools). I prefer working on Unix-based servers. I prefer being able dig into configurations in text files for those times when "standard installations" or "standard upgrades" go south. I prefer knowing where everything is installed and what the dependencies are. I prefer being able to choose the database that I'd like to run. I like being able to setup test machines without worrying about licenses.

That said, I have yet to see a solution that provides as much as Sharepoint, as simply as Sharepoint, and as cheaply as Sharepoint... especially in a Windows environment.

+13  A: 

I work full-time with SharePoint, and here's what I run into the most:

  1. No support for Parent/Child type relationships on forms, you have to do a lot of manual work.
  2. SharePoint Designer pretends to be Visual Studio but lacks or hides some of the simplest functionality.
  3. Deployment. If you develop on one server, and want to deploy your site/solution to another server, good luck! Behind the scenes everything gets tied-up with GUIDS, so you have to know what xml files to edit, and where everything goes.
  4. Error messages in SharePoint are horrible ("An Error Has Occurred!") and trying to find anything useful in the log files is an exercise in frustration. SPD also has this problem.
  5. Branding and visual design is a pain, and there are no good tools for doing it. Prepare to edit a lot of HTML.
  6. CAML is counter-intuitive and useless for anything complex.
  7. You can only use the SharePoint objects to talk to a site running on the same machine as your code. (Eg: SPSite can only access localhost)
  8. Support in Visual Studio is only through extensions, and even then it makes crazy decisions about what a solution should be (I want a solution that creates a site with 2 lists, but VS makes it difficult)
  9. Lousy, Lousy, Lousy documentation. Many things are poorly documented, and many other things aren't documented at all! (Try doing a caml query on the ID in a lookup field, you can, but Microsoft sure won't tell you how)
  10. The "Title" field. How I hate it. You can't get rid of it, you can only hide it (by using custom content types) but because of the inheritance on columns you'll have a hard time making it useful.
  11. No multi-column lookups, or lookups from other sites without 3rd party addons
  12. Workflows have to be reattached to lists when deployed.
  13. Setup and administration complexity
  14. I could go on, but that covers the major points...


  1. It's brittle. Post-deployment changes to custom workflows/sites/etc can be painful. You really need to test, test, and retest your deployments lest you run into unforseen issues after an upgrade in production.

Also, a lot of development issues have been resolved in SP2010, but I haven't worked with it enough to figure out what is working now.

Andrew Lewis
Re 4 about error message, you need to set CallStack="true" on the SafeMode node and mode="off" on the CustomErrors node in web.config to see developer-friendly error messages.
Bjørn Stærk
@Bjorn that doesn't always help (although it does make a big difference)
Rex M
+1 for the title field... hate it too
+2  A: 

I agree with a lot of the other users here have mentioned. One thing I might add is the poor performance of lists that contain many items. We once managed to get three million items into a single list, but after that happened it was impossible to clear those items or delete the list from the web GUI and from the SharePoint API. We managed to get rid of the list by applying batch CAML (yuck!) delete queries to the list.

Oh, and another major complaint that a lot of my customers have: SharePoint Search doesn't support wildcard (i.e. substring) search in the out-of-the-box Search Centers. This means that if you look for the word "share" it will not find "sharepoint". You have to rely on third-party software or code something yourself to fix this.

Considering the fact that SharePoint is positioned by Microsoft as a strong (enterprise) search solution this is a major shortcoming.

There *is* some OOB way to get wildcard search working without third-party or coding but agreed, it should be in there by default...
ROXORITY SharePoint Web Parts
Really? Which way? I've searched a lot and haven't found it yet...
+1  A: 

Sharepoint suffers from performance issues. Other portal solutions do a lot more with less impact on the user. How often does iGoogle reload the page? It's not nearly as often as when configuring Sharepoint web part pages.

+1  A: 

Searching and indexing is a little bit unmature. Noone can explain why indexing takes so much time

Lack of transaction support, referential integrity... a lot of things are just to complex to manage...

+4  A: 

In short, Sharepoint's HTML is not W3C compliant, and this is a BIG hindrance when you start customizing the UI. It is extremely difficult to apply any type of sophisticated CSS as there is an overuse of HTML tables for the web parts. Also, there are very limited use of DIV's. Fire up Firebug and inspect a web part - all you see are nested tables, with no footers so good luck applying rounded corners to the top AND bottom of the web part.

Another BIG short coming is all the inline javascript, and this makes it hard to determine when the DOM is ready for manipulating.

If you have customer base like we do, you find that want to introduce a Web 2.0 interface, and you can integrate jQuery into the frame work. This takes a lot of effort, but it's worth it when you get it working. My team found the jQuery articles at EndUserSharpoint to be key for us gaining control of the DOM.

David Robbins
+1  A: 

Sharepoint doesn´t think about some internet Connections. It´s hard to load the pages and it´s a challenge to deal with performance in the plataform!

We have a Customer that always asks the consulting firm about the performance and how slow is the front page.

I hope Sharepoint 10 can deals better with this Slow mode on!

tks ernesto

+29  A: 

After considering all the various issues mentioned in the specifics, I guess I'd summarize it by saying that the biggest problem is that you end up working on SharePoint instead of working on the problem you're trying to solve.

le dorfier
The number of times I've had to debug SharePoint and work out why it's not working (rather then my solution to the customer) is a joke. With those stupid, vague error messages. Without Windbg, I'd be stuck!
Jason Evans
+1 very true, this is the exact problem
+1  A: 

Just plus nuances:

  • CopyTo, CopyFrom are buggy with custom lists
  • Crazy exceptions and error messages
  • The out-of-box mailserver it's more than simple
  • List item properties and attributes works un-un-unbelievably wrong and lavish with large dataflows
  • Erratic logging
  • And the biggest delusion: Microsoft Sharepoint helpdesk

My inner-question was always as SPS developer: why so much for SPS marketing, and why so little for SPS development?

+3  A: 

My biggest complaint is the development experience as a whole. Everything from setting up a development environment to deploying customizations to simple tasks like trying to customize the styles. To sum things up, developing anything for Sharepoint will take 3x as long as will end in failure.

+7  A: 
  1. There seems to be a bunch of ways in which to do every task and no one indicates which is the right way to do it. Take public websites, do you create a new Site Template to restrict the available page layouts, or do you just add your own page layouts to the Publishing Web template? I've had people tell me both, but neither with convincing arguments as to why they are right. Or how about a Contact Us form, do you make a Web Part, a user control hosted as a web part, expose the Create for a SharePoint list or create a custom Page Layout with an embeded user control?
  2. Development environments are impossible. Since you have to install it on a Win 2k3/ 2k8 (without hacks) to do any kind of custom dev you also need Visual Studio (in some form), and really you need SharePoint Designer (which was a licensing nightmare until a few weeks ago). But then try and do development with more than 1 person on the team, either you share a server, you have a shared farm but separate instances, or you have entirely separate instances. Each with pros and cons, and again, never found anything a good way
  3. The only worthwile documentation and development tool I've found is .NET Reflector. When I'm doing a SharePoint build I live within Reflector. I have read more of the SharePoint API (and got an understanding of it) via Reflector than through all the MSDN documentation, blogs and books I've read. I don't know how it would be possible to develop for SharePoint without it
  4. The SharePoint menu control is sealed (enough said, and yes, I know the source is available, but still, how do you stuff that one up!)
  5. SharePoint Developer != SharePoint Administrator. I can't count the number of times I've had to state that one to project managers and clients. I can do things in SharePoint with code, but don't ask me how to do much within Central Administration unless you're happy to pay me to hours/ days/ weeks investigating how it may be done first. And even then, don't expect me to work it out
  6. Mixed-mode authentication sites. Yeah, find documentation on how to do a custom role and membership provider for SharePoint. I'm not talking using the Sql ones, try and find a completely custom role provider. Sure it uses the standard ASP.NET membership, but I couldn't get it to just work

what sharepoint supposed to do? is it the same as svn?

+1  A: 

IMHO sharepoint is a good idea ruined by an awful implementation, but I can't say I've noticed sharepoint developers are any stranger than the rest of us.

+5  A: 

well there's many reasons but here are the most common I hear about.

  1. Sharepoint is very restrictive. You have to work within a very specific set of confines which can make trivial tasks seem impossible at times.

  2. Working with the security model is complex. It's an enterprise security model with enterprise complexity.

  3. You're essentially working within a hosted environment which can vary greatly from production to test to development. You need to make sure your development environment resembles exactly the production environment or you're going to have pain.

  4. There are so many extra steps to setup, administer, configure and deploy your sharepoint code. It's not easy to automate builds and it's also hard to replicate settings across multiple environments.

What would be a good alternative?-enterprisey
I think this sums it up nicely, but understates the pain.
Todd Stout
+1  A: 

I'm no expert in SharePoint but my guess is that 1) it is very unopinionated and 2) sets extremely high expectations amongst business stakeholders.

Applications can have opinions?
@shog9: yes, check out this questions:
Interesting... How would you say this applies to SharePoint then?
I'd say it uses overly generic metaphors (list, workflow etc.) that do not seem to suggest any golden-way whatsoever, while still, like somebody else said here, constraining your choice of metaphors to those present in the system.
+40  A: 

Edit: after an additional 18 months of leading one of the largest Sharepoint WCM deployments in the world, are these reflections still true? Yes.

I can't speak for all developers, only myself (but I suspect I'm not the only one). I have been working deep down in the EWCM side of Sharepoint/MOSS for about two 3.5 years now, and it has been the most wholly unpleasant of my career from a technical standpoint. I love my job, my company, my coworkers, my environment but the platform is a nightmare.

I struggle to fully articulate objective reasons why this is the case, but ultimately it's just not rewarding. Most of the time we developers tackle a problem and get satisfaction out of mastering the system. However, the more I learn about Sharepoint and the more I feel I've "mastered" it, the more I wish I didn't know anything about it. (Whether it can actually be mastered is another discussion altogether).

It's fun and easy to knock the product as crap, but I don't know the people who wrote it or why they designed it the way they did, and they may have had good reasons. It is a solid document sharing/collaboration platform. However, Microsoft has tried to make it so much more than just that. At an architecture astronaut level, it might seem like the fundamental patterns of a document management system are also the good basis for things like, say, an enterprise web content management system - so they built that on top of it. But in practice that may not be the case, and indeed there is a good bit of friction trying to force an EWCM paradigm to fit the Sharepoint model.

Sharepoint is touted as an application platform, but its usefulness ends at making very simple, basic web-part-widgets that get dropped on to a page. If you need to do deep, core application development using Sharepoint and MOSS as the foundation, it is extremely painful.

It was also shipped prematurely. Important things like application lifecycle management, maintenance and enhancements for systems built on top of Sharepoint seem to be afterthoughts at best. Nothing was built with post-deployment changes in mind. It also breaks some really useful things that come out of the box in ASP.NET, like donut caching.

Tools support is only now starting to catch up. Visual Studio 2010 will have some nice tools for Sharepoint development, but that means the community has spent more than 3 years hand-tweaking hundreds of overly sensitive XML fragments and using the command line for complex deployment work.

Architecturally, the system is extremely fragile. It's a black box, with many moving parts which are clearly loosely coupled, but the precise nature of the interactions between various subsystems is opaque at best, and it is alarmingly easy to take a MOSS site down. A bit anecdotal, but out of the maybe few dozen production deployments we have done so far, something different has gone wrong inside MOSS every time. A timer job fails to kick off, one of the servers in the farm doesn't get all the right files, the content database gets locked or worse.

I could go on and on (I might come back and add some more) but I think my point is clear - Sharepoint is great to pop straight out of the box and onto a server for collaboration and document management. Nothing else. The attempts to make it do more than that is precisely what has broken the souls of so many developers.

Rex M
Well said, you've confirmed my suspicisions having spent a few tortuous weeks battling with the mess that is Sharepoint/MOSS. Have you found a better alternative? After all document sharing and collaboration spaces are all the rage in Web2.0 organisations - or is that just hype?
@MrTelly next-generation collaboration is definitely the future of all organizations, web2-0 or not. Sharepoint is just not the product to do it.
Rex M
Clarification: Sharepoint is not the product to do *all* of it. It'd be acceptable as a small component of a much larger system.
Rex M
As a budding SharePoint developer I found your response pretty interesting. I've been placed on a maintenance project for an existing WCM portal and have taken an interest in learning the "ins-and-outs" since there's such a lack of SharePoint experience. Do you feel that Microsoft is making an adequate attempt with 2010 to improve the customization experience for developers? Not only through performance/stability improvements, but through more integration with Visual Studio?
@UnhipGlint the tooling support looks like it will be more than adequate with VS2010. The API is mostly set in stone though, so I don't expect any improvements there. I haven't seen much one way or the other from an architectural standpoint (application maintenance, etc) so it may or may not improve.
Rex M
this has done me a world of good to read. I thought I was losing it big time. Perhaps I don't need to change career after all...
@Rex This is full of truth!
Chris Ballance
+1  A: 

I have worked with SharePoint ever since the 2001 version (if you thought 2007 was bad, 2001 tops that easily).

I see developers struggle with SharePoint daily, it seems a lot of people have problems with the steep learning curve. Yes there is a lot to learn. If you know SQL and ASP.NET you are simply not there yet. It is hard for a single person to know 'everything' about SharePoint. It's a bit like the ads of companies that are looking for a PHP developer that knows ASP.NET very well, masters Flash, Photoshop and can talk to clients about requirements. Unlikely.

Community support for SharePoint has been high; there are loads of community sites, people creating tools, add-ons, etc. Someone mentioned terminology, type in "SharePoint searchterm" in google and you rarely miss, even if your searchterm is something generic such as "page" or "content type". Uptake with companies seems equally high, many use it as their Intranet platform and not only the small ones.

I for one like working with SharePoint. I would not want to go back to building Intranets or document management type applications from scratch. Yes you have to have some infrastructure in place; a Windows Server to develop on. Still I can do 'create webpart' in Visual Studio, choose 'deploy' in Visual Studio and be looking at my code rendering on a SharePoint page 2 minutes later. I won't say getting this set up is trivial but it is not that hard either. Also, WSS is free (if you have Windows Server).

If do have a question.. I'll admit to being very biased towards Microsoft & SharePoint because thats what pays my bills but what would the alternative be? (There is no single answer to this question because SharePoint can be used in many ways, I know.. still wondering though)

+1  A: 

Lots of people complain about the fact that you have to develop on a SharePoint server within the farm (unless using SP or custom web services.)

But SharePoint is an ASP.Net framework. If you were developing a stand alone ASP.Net site you would also have to develop it on an ASP.Net server (it would just be your local machine), there is nothing stopping you from installing SP on your own VM and developing your solutions there. The only limitation on developing on your desktop machine is the OS (this is a server based product after all.)

+4  A: 

There's a saying around my office:

Sharepoint is slow.

+2  A: 

That it's quirky and its quirks are badly documented. For example, editing a web.config file locally with SPD was a logical enough thing to want to do, until I discovered it had covertly created a ton of folders to stay frontpage-compatible, without telling me (I found a tip in big, bold letters in a SP book - Professional Sharepoint Development, I think, along these lines - "Don't, whatever you do, use SPD locally, but only remotely via http!!!"

And secondly, when deploying a workflow .dll with SPD, if you leave SPD open, it will cunningly cache the .dll by renaming it, so what you think you just deployed to the GAC, is not actually what the SP is using.

+2  A: 

If you want to debug SharePoint errors, then you're going to need Windbg since all you'll usually get is 'An unexpected error occurred' or something useless like that.

Cheers. Jas.

Jason Evans
+1  A: 

The most frustrating thing so far for me having not customised the sites much is the idea that i attach an AD group to a Sharepoint group and yet the AD group is listed as a Sharepoint group in sharepoint.... I dont want to see hundreds of AD groups in sharepoint, just the groups that are directly associated to the sites... it just makes life complex when browsing the site groups... pian in the arse....

+1  A: 

What gets me most are the whiners. This product is powerful and flexible enough to pretty much achieve anything you could ask for in the enterprise collaboration/CMS arena. Developers just have to get their heads around the fact that there is a relatively steep learning curve involved. But that's what we get paid for, right? ;-)

progress is about making things better, not living with dung
Have you got another CMS that can scale like SharePoint? Or does your dung not smell?
Hear hear.. +1Embrace the SharePoint ;)
As a developer, I have embraced SharePoint for what it is. Is it powerful? yes. Is it perfect? far far from it. Choose carefully.
+1  A: 

SharePoint is full of love, the kind of love that hurts.

1) SharePoint's calculated columns would have been a great idea if Microsoft had allowed us to extend/add functions. For some reason though you get limited to a small subset of Excel functions.

For example, to replace 0 to 4 spaces in a calculated column we had to write something like this. Not only that, but the level of nested calls is limited to 8 making it quite difficult to avoid complexities.

=IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])))), REPLACE(IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), 1, "%20"), IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))))), REPLACE(IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])))), REPLACE(IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), 1, "%20"), IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])))), REPLACE(IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), 1, "%20"), IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])))), 1, "%20"), IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])))), REPLACE(IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), FIND(" ", IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), 1, "%20"), IF(ISNUMBER(FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))), REPLACE(IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]), FIND(" ", IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title])), 1, "%20"), IF(ISNUMBER(FIND(" ", [Title])), REPLACE([Title], FIND(" ", [Title]), 1, "%20"), [Title]))))

2) Importing and Exporting sites containing WorkFlows is a mission because items attached to workflows will not persist this information after importing. (EDIT isue may have been fixed with the latest service pack)

3) You can't do joins with CAML. CAML itself is a big limitation.

4) You can't use a lookup column or a people column in a calculated column.

+4  A: 

Where to start. Guys if you're out there holding your heads, and nearly crying in frustration, you're not alone. I've worked with a department of SharePoint developers, and I've never seen a product stab moral like SharePoint.

here are my observations

  1. Total lack of documentation, and anyone knows the last place on earth you go to get help for SharePoint is from a Microsoft site. Instead you find developers kind enough to write blog posts, usually ending in "Happy Hacking"
  2. The product has a way of smacking you with a ten ton hammer at every single curve. Hardly anything works as you would expect it to, and it takes severe effort to get things working.
  3. The object model only works on the same server as the SharePoint server, so any external systems must use web services. Not bad right? Except the web services don't expose the same methods for example: GetListItems from web service method only ever gets what you pass in the viewName.
  4. Development usually involves using virtualization, and running your visual studio inside of that.
  5. 32/bit issues that you're bound to find because you are developing on 32bit, and implementing on 64bit
  6. Extreme Knowledge of all of the above to master SharePoint (IIS, XML, CAML, Windows 2003/2008 Server, Active Directory, C# or,, SharePoints internals) When I say extreme - think you're a 10/10, you need to be a 20/10
  7. Developing even the most basic of functionality takes long, developing complex applications takes 3-4 times longer than any project manager who doesn't know the details would ever dare to think
  8. The Microsoft SharePoint evangelists - who tell you what a great product SharePoint is - and tell you CAML is here to stay
  9. CAML is a prototype, its buggy and its terribly complicated
  10. Lack of feature receiver events means having to wrap features in features, and the MOSS team are proud of this, and embrace it, instead of fixing it.
  11. 401 Unauthorized exceptions you can't get rid of, no matter what you try, and no one else can either
  12. The way a sharepoint site takes over IIS completely and you can't host stuff side by side it
  13. The way web parts and pages mess with your javascript and ajax functions, and stuff just never getting called or firing too late
  14. The way it just looks all good on the surface, and you have non IT people floating around thinking its a real product, not a demon
  15. The way no matter what you tell non techs, no line manager would ever believe its such a debauch product
  16. The error log, what a disaster
  17. Still don't really understand the difference between a web app and a site collection, do you?
  18. Site definitions - just makes me feel sick thinking about it
  19. List performance (we recommend 2000 items per view)

But the worst thing with MOSS is that there is an unwritten rule only to ever query MOSS through its terrible CAML or web service methods. So any junior who might think it would be a good idea to write some to get list items or any other sharepoint object - will get shot down!

I really hope 2010 takes the MOSS out of MOSS. Its the only technology I truly despise.


SharePoint has only one absolute truth.

"If something works on the Framework, DOES NOT means it will work inside SharePoint."

Living by that you won't end up making tests/implementations outside SharePoint with the "Then I'll just copy the code inside that webpart" mindset.

I cannot stress this idea enough, get a good development environment, talk smoothly to your CAS restrictions, understand the impersonations done inside the 12 folder (14 in 2010) and know beforehand that the API probably HAS that one method you need but they ensured it was marked as internal just to test your reflection skills. (GetListByName() being the best example I have in mind).

SharePoint needs a Windows 7 take for the future. Redone from the ground up, no unmanaged STS COM to talk to the database and better structure in the todays homebrew Object Model/API.

+1  A: 

Perhaps to illustrate SharePoint 2007 frustration when it comes to customizing its look..

            Hello, SharePoint!

Luckily, Microsoft has heard/learned and 2010 will be full of enjoyable divs...

+1  A: 

It versions files, but doesn't make comparing versions easy. Even text files or Word files that you figure Microsoft can handle. You can't (as far as I know) revert unchanged files.

Brian Carlton

It is just incredibly complex, compared to what it achieves (compare to N2 CMS for example).

And who came up with the idea that in order to derive a content type from another, you assign the id to be <id of parent>00<new id>? I really hope that person is not working on anything I will have to touch again.

+2  A: 

I was going to keep a running list of grievances in a Word document but I'll just do it here instead. Not evening touching on the user experience aspect of it, here are just a few of the infuriating issues that you WILL encounter if you touch the API:

  1. Uncatchable COM exceptions.
  2. Instead of using .NET generic collections they have their own nimrod collections that don't even have basic methods you would think are intuitive, eg: UserList.Contains(user).
  3. The aforementioned collections throw COM exceptions when you make even the slightest mistake, like trying to delete a user that doesn't exist from a user collection.
  4. If you are lucky enough to get a catchable exception you'll end up with a helpful error message like "Value does not fall within expected range."
  5. Important functionality such as telling it not to bind MS Word Document metadata properties to a list are controlled by obscure members called things like ParserEnabled with, guess what... little to no documentation.
  6. Doing something like querying a SharePoint site to see if a list exists requires using try/catch blocks for flow control. Top notch MS! Top notch!
  7. Trying to get a field within a SPItem is a comedy of errors, especially if people start renaming it. item["fieldName"]? Nope. Try item[item.Fields.GetFieldByInternalName("internalName").Id].
  8. Properties such as Hidden, Title, etc, which are common across many SharePoint classes are NOT encapsulated within an interface, but are instead declared separately in each class. So if you want to do something like show all hidden stuff on a SharePoint site, well you have to cast everything separately.
  9. To remove users from a site collection you have to call the "SiteUsers" property on any arbitrary SPWeb under that site collection - WTF? See here.
  10. Ditto for groups.
  11. Whoever did the documentation was lazy and/or didn't give a rat's behind because 99% of the time you'll find that it's either missing or worded like this (straight from MSDN): "SPView.BaseViewID Property - Gets the ID of the base view for the view." Yes, very helpful. That was exactly what I was looking for. Thank you, Microsoft.
  12. Content type inheritance. If a document library is 0x0120 then it's only logical that my child content type is... 0x0120000179B99E08755047B72F8136BBEEA6B9!?!?! Oh, the humanity!

I did some research into the history of SharePoint in order to understand why it is what it is, and stumbled upon some gems:

All of this leads to the following conclusion: SharePoint is the frankenstein progeny of FrontPage Server Extensions, plain and simple. That's why its API stinks so badly and why it has a host of nasty COM objects at its core. I would even wager a guess that large blocks of code at the heart of the SP code base are the original ones that Microsoft stole... er, acquired from Vermeer. In other words, it is likely that parts of SharePoint are over 16 years old! No wonder those error messages are so cryptic. This is technology from 1995! Its roots are plain for all to see: vti = "Vermeer Technologies Inc". When I came to this revelation I didn't know whether to laugh or cry.

Repo Man