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 ^[1] 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 ^[2]. 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.

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.

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.

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 ^[1].
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!
13. All the subtle nuances and inconsistencies which drive you insane. Example: in one place all of your GUIDs must be uppercase. In another place your GUIDs must have curly braces around them. Everywhere else it doesn't matter. Umm... how hard is it to write a GUID parser and reuse it everywhere in your code base?
14. The "S" word - schema.xml. Get ready to rip out all your hair. The practice of provisioning a list definition is the most essential, and yet most convoluted task you'll ever do in SharePoint. The way you go about it is much the same as it was in 2003. Seriously. SP2010 is marginally better in that it doesn't use "CAML spit" (replace the "p" with an "h" for a better name) to render the views anymore, opting instead for XSLT. VS2010 also does much of the work for you via the UI integration but it only takes you so far. Start doing something fancy like deriving from the Discussion List and suddenly you're in a world of hurt.
15. The "l33t sp3ak" hiding in MS's out of the box GUIDs. This one sounds nit-picky but after wasting a whole afternoon wading through XML it'll start to get on your nerves too. For example: 00BFEA71-1C5E-4A24-B310-BA51C3EB7A57 (00BFEA71-1C5E = "Out of box feature", BA51C3EB7A57 = "BASICWEBPART").
16. Everything is a GUID. Not only does this smack of laziness on the part of the SharePoint team, but it also means that SharePoint solutions are very brittle, tedious to engineer, and difficult to export from existing sites. Oh yeah, and it guarantees that customizations built using SharePoint Designer will never ever work on another site.
17. Writing functionality that operates on one specific list instance (instead of all lists of a certain type) is exceedingly painful and almost always requires hackish workarounds. Example: custom actions.
18. SharePoint's idiotic handling of master pages. Why is ~masterurl/default.master a replacement token instead of just replacing ~masterurl? Once again my code-smell sense is tingling and something tells me that they cut corners on this. I've also found that ~site and ~sitecollection do not always work as intended. There's nothing more beautiful than getting a yellow screen because SharePoint replaced ~sitecollection with the text "sitecollection" instead of the URL to my site collection.
19. Field internal names can't be longer than 32 characters. If you try to create a field internal name that is longer than 32 characters it gets truncated without telling you. Why? Probably because back in 1995 when the Vermeer guys (see below) were building FrontPage they said "Gee, my 100 megabyte hard drive can't hold a database that's too big. Why don't I make this field a VARCHAR(32) to save space..." and history was made.
20. The atrocious naming conventions. A "feature" is a module that a user activates. A "module" is a logical file copy/path. A "schema" is a list definition. A "template" is a list definition that has been made available to the user via the UI. And of course - SPSite is a site collection and SPWeb is a site. Uh, what?
21. EVERYTHING IS A GUID!!! AHHHH!!! - This is a reiteration of point 16 because it is such a critical flaw in the design of SharePoint and probably the single biggest reason NOT TO USE SHAREPOINT. EVER. If you ever try to export web parts, either manually or through code, sooner or later you will find yourself in GUID Hell. Case in point: List View Web Part. Never mind that my list on Site A is identical in every way to a list on Site B - because my web parts point to globally unique identifiers, they cannot be exported and reused. Sorry, try another way. There are so many different designs that SharePoint could have used instead of "everything is a GUID"... for example, why couldn't they use a namespace-based approach to identifying objects? My list ID might be: MyCompany.MyTeam.MyList. If that were the case, then anything pointing to that list would be exportable. Instead they took the easy way out and now you, the developer, pay the price.
22. CAML - a.k.a. "Crappy A** Markup Language". Technically this complaint overlaps with some of the other ones, such as #14, but it's important enough to be included on its own. Do not believe the lies - CAML is not going away any time soon! And those of you who try to be good little SharePoint developers, doing everything "by the book", understand that there isn't much you can do declaratively (in CAML). And of course that means that you're stuck writing a bunch of messy C# code in event receivers just to do something simple like wire up a quick launch link to a list you just created. Those who value their sanity will write helper classes to do all these seemingly repetitive tasks (because the API also falls short for most of them) and a very few intrepid individuals may take it a step further and slap their own ad-hoc scripting language on top of it, which for all intents and purposes serves as a replacement for the abomination that is CAML. Yet the truth remains for all to see - CAML sucks, the API sucks just a little bit less, and either way you go it's going to be painful.
23. SharePoint is "special". So "special", in fact, that it doesn't even play nice with other Microsoft products. Case in point: SP2010 integration with Reporting Services. Get ready to look like Telly Savalas because this will make you rip out whatever hair you have left. No joke.

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

• http://blogs.msdn.com/b/joelo/archive/2007/12/28/7-years-of-sharepoint-a-history-lesson.aspx
• http://www.seoconsultants.com/frontpage/history/
• http://en.wikipedia.org/wiki/Vermeer_Technologies
• http://edinkapic.blogspot.com/2009/05/what-sharepoint-and-vermeer-have-in.html
• http://tech.kateva.org/2008/06/vermeerfrontpage-lives-in-sharepoint.html
• http://blogs.iis.net/robert_mcmurray/archive/2008/04/17/life-after-fpse-part-1.aspx
• High Stakes, No Prisoners (book) ^[2]

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.

Discussion (why SharePoint is horrible)

What is software? A piece of software is a machine built entirely out of pieces of logic (typically) in an iterative, fractal, emergent process. What is important here is the whole fractal/emergent process by which the software develops. If a system is built upon solid requirements, a holistic vision, and good coding practice, then as that system changes and evolves over time it will develop into something that is intricate, yet beautiful, that scales well, and is easy to extend. However, if a system is built from half-baked requirements by sub-par developers, then it will instead grow like a cancer into something that is unsightly, difficult to maintain, and ultimately unsustainable. It all comes down to beginnings, the germination phase, as it were. And that brings us back to SharePoint.

As outlined above, SharePoint entered existence as an ill-conceived product called Vermeer FrontPage, way back in 1995/96. It was supposed to be something which enhanced the user’s web experience, which made all the new technology more accessible to the less tech-savvy people, but in reality it was a silly product from an even sillier time in history. More cynically, one could speculate that it was a slopped-together piece of vaporware pawned off by a couple of non-programmers onto an unsuspecting mega corporation, Microsoft, with the belief that it would never again see the light of day. Unfortunately, it did emerge again, but as something new and warped and terrible to behold.

It’s likely that Microsoft, eager to recoup the $133 million that they spent to purchase FrontPage, started dumping countless man hours into the product in an effort to make it something worth selling in the brave new world of post dot-com software. However (remember what I said above?) software which starts out from a poorly designed, tenuous architecture will only get worse over time. And that’s exactly what happened.

SharePoint, at its heart, is a convoluted mess of anti-patterns and Rube Goldberg-like contraptions all operating behind a black curtain. To be more specific, it’s a bunch of tightly coupled COM objects which are wrapped inside .NET objects. Now, it’s anyone’s guess as to what’s hiding inside those COM objects, but for those of us who are intimate with the product it isn’t a conspiracy theory to believe that there is, indeed, a whole bunch of Vermeer code inside of them. There are clues, if you know where to look, and the horrors of the database schema are there in plain sight for your viewing displeasure. Speculating further, it’s likely that Microsoft only exacerbated the problem by putting their absolute bottom-of-the-barrel programmers and project managers onto SharePoint throughout the years. However, if you place the turd onto a silver platter and surround it with enough delicate trimmings, you can sell it to anyone as filet mignon, and that’s exactly what they do.

To conclude: caveat emptor—buyer beware! Know what you’re getting into before you sign your name (in blood). Expect a colossally high programmer burnout rate when working with this product, especially when you start deviating from its original intended purpose, back when it was still known as FrontPage… which was?

Merely a WYSIWYG editor, with the ability to throw some widgety things onto a web page.

Fin.

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.

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.

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

Addendum:

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.

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 ^[1] 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&*%.

http://technet.microsoft.com/en-us/office/sharepointserver/bb507202.aspx

http://blogs.msdn.com/joelo/archive/2006/08/23/key-governance-considerations-in-a-sharepoint-deployment.aspx

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

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

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.

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.

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.

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 vb.net, ASP.net, 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 ADO.net 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.

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

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

There's a saying around my office:

Sharepoint is slow.

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.

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 ^[1] to be key for us gaining control of the DOM.

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.

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

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.

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.

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

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.

Microsoft.

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.

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.

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.

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.

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.

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

<table>
   <table>
      <table>
        <table> 
          <table>
            Hello, SharePoint!
          </table>
        </table>
      </table>
   </table>
</table>

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

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.

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 ^[1], 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.

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

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

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

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?

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)

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.

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.

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.

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.

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

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

Just struggling through some customisation at the moment...my main PAIN has been the uselessness of Lookup columns. Sure you can use them to join lists to present data, but using data from the lookup list in a form is far too much work!

Lookup cant be part of expressions....

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? ;-)

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.