Tuesday, October 13, 2009

SharePoint Sucks – And Here’s Why – Part 3

As promised, here’s the third installment of my reasoning of why I think SharePoint sucks. I’ve written two posts already, and if you land on this post, you may want to check out the previous posts first.

In the first post of this series, I nagged about how Bill Simser marketed SharePoint as a mediocre solution to a whole range of problems, arguing that if you settle for a mediocre blogging platform, you’ll get a mediocre wiki solution free of charge.

In the previous post of this series, I mentioned a few reasons why I think SharePoint sucks. However, and as several people noticed, only one of the items were really technically about SharePoint. The remaining posts were about how SharePoint was marketed both by Microsoft and the SharePoint fauna.

I also wrote a meta post to answer some of the community comments. Since then, more blog comments have been posted, and likely some that I’ve not found as well.

So, in this article, I thought I’d mention more reasons why SharePoint sucks, why it’s a faulty product, and why Microsoft had better be darn impressive with their next version, SharePoint 2010, soon to be available as public beta.

Code Quality

If you’ve ever tried to reflect the SharePoint DLLs, you may have encountered rather curious constructs. Here’s an example from SPList and it’s HasExternalEmailHandler property:

internal bool HasExternalEmailHandler
{
    get
    {
        bool flag = false;
        using (IEnumerator enumerator = this.EventReceivers.GetEnumerator())
        {
        Label_002D:
            while (enumerator.MoveNext())
            {
                SPEventReceiverDefinition current = (SPEventReceiverDefinition) enumerator.Current;
                if (current.Type == SPEventReceiverType.EmailReceived)
                {
                    goto Label_0037;
                }
            }
            return flag;
        Label_0037:
            flag = true;
            goto Label_002D;
        }
    }
}

This is actually one of the easier examples to understand; you’ll find plenty of goto constructs and variable naming that will leave you crying for mercy if you try to figure out what’s going on. The fact that it all works is probably a bigger mystery than Loch Ness.

Security

How can, by the deities, any product be recommended as a front end for public web pages when anyone able to append _layouts/importpolicy.aspx to a URL can take down the entire installation? SharePoint security and permission handling is a nightmare, and as I’ve previously written, anyone looking to use SharePoint as a web front end had better

  1. get their heads examined
  2. hire some seriously skilled security people
  3. prepare for some serious stability and security issues

    or, more often than anything else
  4. fire their advisors who put them up with SharePoint as a web content management solution in the first place

Even Microsoft aren’t able to secure their own SharePoint sites, as I wrote in the web front end article, with presumably the best people in the world of SharePoint working for them. They use a custom solution to prevent anonymous users from seeing their innermost secrets. However, if you have a Live ID you can still see the SharePoint interface of their site.

A solution, by the way, is dead simple, so there really isn’t any reason why it’s not included in the default SharePoint installation. Instead, hundreds of public facing SharePoint sites are open and inviting to anyone with a large enough document management policy.

The permissions model is also a chapter of its own. By use of a very intricate model, SharePoint renders practical use of item level permissions almost impossible, again requiring users and customers to either limit their requirements or suffer performance and manageability issues.

CAML

I’m sure someone, somewhere, knows what went wrong the day that CAML was invented. Was the gods unhappy? Did the person who came up with the idea want to get back at their employer for something?

I want to add a single column to a single view. Just do display something as simple as a single line of text. Let’s see what it takes in, for example, the most basic of lists, the Custom List. In the screenshot below, I have closed the two views that are responsible for displaying the Title column, and only the Title column, of a custom list:

Figure 1

Notice the line numbers? The default view, the one that a List View Web Part uses to display a list, is 1016 lines long. The All Items view, used to list the single Title column in the AllItems.aspx view, is 1130 lines.

No wonder people fear writing custom views more than they fear death, cancer, or Marilyn Manson.

Are You Done Yet?

Hell no! I’ve got more coming. I could go on like this for volumes. I could talk about documentation. Development tools. HTML Compliance, or the possibility of making SharePoint compliant. Or a number of other topics. Not because I know secrets that are not known, but because SharePoint truly sucks.

However, in the next part I’m going to share with you some secrets that may explain why I’m still so fascinated by SharePoint, and why I’m still spending most of my waking hours thinking, writing, or talking about SharePoint.

And it’s partly your fault…

.b

If you like this post or this blog, please visit the sponsors from SharePointAds.com and hear what they have to say:

5 comments:

tojonas said...

"you’ll find plenty of goto constructs and variable naming that will leave you crying for mercy if you try to figure out what’s going on. The fact that it all works is probably a bigger mystery than Loch Ness."

The reason for this is mostly that the code is obfuscated...

Reflector can also generate this code since the IL generated from an foreach statement actually is implemented like this, with gotos.


Don't assume that you get the 1:1 source code by using Reflector.

Thanks
/Jonas

Bjørn Furuknap said...

Jonas,

That's very good to know, I've always wondered what kind of tool generates such code, as it would be improbable that humans would write such a thing.

However, the goto-stuff is really just an example of bad code in SharePoint. Other code, for example non-obfuscated ASP.NET code, suffers from bad coding practices as well. Another example is the dubious implementation of SPWeb and SPSite disposing, or lack thereof.

.b

Bil Simser said...

Goto labels in reflected code is *not* goto code in the source. Disassembled code cannot handle things like LINQ queries or even simple try/catch/finally blocks. So they substitute labels to try to compensate. Judging the quality of any app based on disassembled code from an obfuscated assembly is juding a book by it's cover.

Bjørn Furuknap said...

Hi Bil, I'm glad you decided to join in...

Not sure if you have been holding on to that comment for a very long time, or why you weren't able to see the comment just above yours, but as you apparently missed, I mentioned that this was simply an example.

I'll assume that means you agree with the rest of the post, though.

.b

Bil Simser said...

@Bjorn,

I did see your comment. You said "However, the goto-stuff is really just an example of bad code in SharePoint." I'm saying it's incorrect to judge the quality of a product (any product) from disassembled code via reflection of an obfuscated codebase. That's like basing your opinion of a movie from a critics review that never saw the flick. Reflected code is what it is but is not representative of the quality of the codebase written, it's a reflection of the tool that disassembled it (good, bad, or otherwise) and only conveys intent and some implementation details but not the entire picture. Necessary but not sufficient. Also you're taking a single method as an example from a codebase that has what, 500+ classes with 20+ methods in each? Back to your original statement I quoted, you're saying this is an example of bad code in SharePoint and that's not doing the product justice or making a fair comparison.