Many years with SharePoint, and I certainly have many small secrets which help me to successfully struggle through notorious and widely blamed SharePoint thorns and gotchas.

And one very good thing to know - is what you should avoid in SharePoint. This comes only from real experience: when you read about those features on MSDN or TechNet or fiddle with them in pet projects they look nice and appealing, but then you start using them in real-world projects it often becomes a disaster.

My top5 of very popular SharePoint features which I would try to avoid at any cost I want to share today.

1. SharePoint Mapped Folders

SharePoint Mapped Folders is most likely the very first feature you started to use back in 2010 (and so did I). And before there was WSPBuilder, using the same principle... And it was so handy, wasn't it? You merely create an ASP.Net web page, put it into a mapped folder, and woo-hoo, it's inside SharePoint! You put images and javascript files there, user controls, resources, and so on...

NO, I wouldn't use SharePoint Mapped Folders. I would try to avoid them as much as possible. Because SharePoint is not ASP.Net! SharePoint has it's own way of doing things, and although it perfectly allows you to stick back to ASP.Net, and even supports that in a way, the other approach ("The SharePoint Way"!!) brings much more benefits and gives the full SharePoint power into your hands.

I would say, keeping back to ASP.Net in SharePoint is like keeping working on Windows 98 virtual PC after installing Windows 7 on your computer :) Well, it works, but it's just silly you don't gain any benefits of new OS features :)

And yes, can't resist mentioning that in terms of new SharePoint 2013 Apps and all this cloud business the mapped folders just don't exist at all... ;)

So, "no" to SharePoint Mapped Folders!

2. XML Definitions

Surprisingly, XML definitions is another thing I would try to avoid. Well, short XML things are perfectly fine but the "long" fellows like List Schemas, Ribbon Customizations etc. are very hard to maintain, upgrade and troubleshoot. So if you are engaged with a long-lasting projects with no direct access to production, or you're creating an enterprise solution, this is a thing to consider.

Quick example: if you try to deploy a list (defined in XML) and there is already some other list with same title, it will throw an exception and you can do absolutely nothing to prevent or fix this! XML is not that flexible in SharePoint and this is what you must always keep in mind.

So I would prefer replacing complex XML things with programmatic actions. Perfect example is the Fluent Ribbon API opensource project which does exactly that: replaces complex ribbon XML definitions with easy to maintain and organize code definitions. Say, if you have a ribbon tab group with tens of controls inside, you can easily put each tab or control group in a separate file or folder or whatever, organize it as you wish, generate it dynamically and whatever, because it's just C#! Not mentioning intellisense and on-fly validation and many more useful things... And all those things are missing in XML.

The same holds true for content types, lists, libraries and many others. Don't create them with XML. Use code. It's so much simpler. Write a lib for that if you must. It will prove useful. And say "no" to long XMLs! :)

3. Custom Field Types

Custom fields types is again a thing to avoid. Such fields are readonly in Datasheet view in 2010, and also don't quite work in Document Information Panel in Office, and for example they cannot be a target for lookup fields and many other limitations.

Good foundation for creating custom field types is definitely a big loss and something what SharePoint lacks, well at least 2010 version and before. "Emulating" custom field types involves much XSLT and JS and don't work everywhere either, but in SP2010 it was really much better approach when custom field types.

There are some changes to this in SP2013 and I appreciate them greatly and hope for the best, though so far I can't tell for sure that SP2013 custom field types are good enough for production (unfortunately I just haven't been using them long enough). Well, we will see.

4. Visual Studio Workflows

Visual Studio workflows always seemed to be an ugly duckling to me. I never understood why people treat them as "advanced" version of SPD workflows. You want to include code in SPD workflow? Write custom code activity, it is not a problem at all... But Visual Studio workflows with their whimsical events and lacking of automatic upgrade and all that...

Microsoft seems to finally admit this in SP2013, there Visual Studio Workflows exist no longer (well, only in "2010 emulation mode").

5. InfoPath forms

InfoPath has great idea behind it: business users are able to customize the forms. Great! Awesome! Not true in real life :(

InfoPath forms are really sophisticated. They have numerous bugs: e.g. it is sometimes very hard to make a control one pixel higher than it is now and so on. They lack of modern elements: e.g. there is no tab control, and common method of implementing tabs now (by copy-pasting views) stinks to high heaven... They're difficult to migrate and deploy, and so on.

No, unfortunately, InfoPath is far from being Excel, especially when you design InfoPath forms for SharePoint :( No, no to InfoPath.

Conclusion

SharePoint is vast and heavy and historical. SharePoint is flexible and rich and efficient, in clever hands. SharePoint is awesome, if you know how to use it. But you must know how to use it. And that's why you must know how not to use it :) Consider this. And good luck with your solutions!