Microsoft’s Mixed Messaging on SharePoint 2013

Microsoft has an identity crisis with SharePoint 2013. They say one thing and does the exact opposite, only to switch sides a few minutes later.

I am, of course, talking about the development experience of SharePoint 2013. Not necessarily the hard-core stuff, but how they approach any development in general.

Before you dismiss this as a developer oriented post, however, give me a few headlines to convince you that this actually affects any SharePoint users. I’ve even included car analogies for you!

Don’t Do Custom Development!

The big shiny new toy in the SharePoint developer’s arsenal is the App model. Apparently, Apps are supposed to solve some kind of problem, although Microsoft has yet to say exactly which problem or set of problems that Apps solve.

One problem, apparently, is that people do custom development in the third tier for any minor thing that needs to be done. That, according to Microsoft, is a bad thing because, apparently again, third tier development is so damn expensive, dangerous, and unstable.

If you reading between the lines, you’ll probably realize that the problem here isn’t third tier development, but lousy third tier developers. In other words, some developers are crap, so you shouldn’t do development.

Or, some car mechanics are lousy so you shouldn’t fix your car.

This is fine, if we read deeper into Microsoft’s statements, we learn that what they are really saying is that you shouldn’t do any custom work (including modifying the design and UI) unless you know what you’re doing.

Note: I elaborated on Microsoft’s statements and what they really meant in the blog post Welcome to SharePoint 2013! (Warranty Void if Opened)

So, for the car analogy fans, you shouldn’t fix your car yourself unless you know what you’re doing. Makes sense, right? I certainly think so. Learn your trade or at least enough to not put yourself in danger.

Microsoft’s one message, though, is that they don’t think you can handle that responsibility. Developers are no told that they should default to choosing the App model because it’s safer and can’t cause as much damage. I’ll have a few things more to say about this later in this blog post.

Then, there’s the SharePoint Designer conundrum. Although there are also technical reasons, SharePoint Designer, the de-facto tool for doing SharePoint development outside Visual Studio, gets its wings clipped by the removal of the design view.

One statement I’ve seen say that the cause of the removal is that design view cannot handle HTML5. That’s funny because Microsoft contemplated removing design view from SP2010 too, long before HTML5 was generally available for SharePoint (see Paul Stork’s comment on August 2 on the infamous TechNet thread about the missing design view).

There must be another reason, and combine this action with Jeff Teper statement’s on the “Myspace problem” of SharePoint, and I strongly suspect it’s a deliberate step to prevent untrained people from causing damage.

In other words, Microsoft makes the engine less accessible for unskilled people. Much like most modern cars; you really can’t muck about unless you have the proper tools and training.

Here’s How Easy It Is to Do SharePoint Development!

Then we get the SharePoint App model and Microsoft is back to its roots with making things so easily accessible that you don’t need to know how to spell your own name before you start developing critical business solutions.

With the Napa tools, Microsoft is asking people to completely forget about tools at all. You just need a browser, how much easier can it get?

Oh, and you don’t need to learn any programming languages either, you just need to work with HTML and JavaScript, and that’s so easy, even your mom can do it. Just look at all the tutorials on making timers and manipulating the user experience with jQuery there are out there. You’ll be up and running in no time, tool and knowledge free.

Note: I still haven’t lost my knack for blowing things out of proportion to make a point.

Car analogy: you now get a programming interface for your car that you can start using without having ever driven a car or know anything about how it works. You can make your car do really cool stuff without learning anything about traffic safety, engine optimization, or why people spend decades learning development to build cars that are safe and predictable.

Instead, Microsoft feels that the real power to develop business solutions should come from the business users, who are otherwise engaged in planning quarterly budget meetings or editing papers on quantum entanglement. Those are the people who understand the problem so they should have the power to solve them.

This is also fine, except if you read the first part of this article, where they are actively discouraging anyone from solving their own problems until they know how to do it properly.

So, First It’s Bad, Now It’s Good?

Microsoft can’t seem to make up their minds on whether users should have the power to build solutions or whether it should be left up to those who do it for a living. One the one hand, they discourage modification unless you know what you’re doing and on the other hand they encourage you to build solutions as easy as you can get up in the morning.

One problem I see is the use of JavaScript as one of the main new development languages. I’m not going into a language debate here, I’ll do that another time, but JavaScript is unsuited as an introduction language for anyone. JavaScript enforces no structure and assumes that the developer knows how to best structure their code. However, for the target audience of Napa for example, these developers more likely have a cursory acquaintance with development rather than being full-time developers with the Microsoft-mandated ability to separate crap from raisins.

And it’s not that Apps are safer either. You can mess up as much with the client object models as you can with a server model, with the noted exception that if you really fuck up a client side program, you only mess up the tens of thousands of browsers that access the App rather than the one server. It’s not fewer or less important problems; there are just different problems. None of the existing problems are solved; instead, you just exchange problem set A with problem set B.

The whole security model also reeks of foulness. OAuth, while a good idea, isn’t really implemented at all, in that an App cannot ask for permissions more than once (at install time). This means that if you need something as mundane as checking whether a certain content type exists, you need far more permissions for your whole app than you really need because you can’t ask the user to grant you that access on a need-to-have basis. Nor are the permissions granular enough, by far. You end up with asking for far more permissions that you really need.

Here’s an example.

Let’s say that you write an App that let’s you play Tetris. No permissions to critical data required, right? Well, let’s say you want to save the score on the site. Because there’s no way to ask for permissions to a single list when a user asks to store their score, you need to ask for permissions for the whole site when someone adds the App, essentially signing off on a disclaimer that the app can do pretty much whatever it wants.

The consequence, I believe, will be that Apps ask by default for far more permissions than they need, and users will completely ignore the actual permission requirements because they have no real way of making the decision. It will be about as useful as the EULA; you just click I Agree without having the faintest idea about what the contents of the agreement are.

I will at some point write more about this, but these are examples of why we’re not becoming safer with Apps or with Microsoft’s new attitude, we’re just exchanging problem sets that developers (and now users) need to understand.

So, my point in this, is that Microsoft seems to want to say that they’re taking security and stability seriously, but at the same time they reduce the requirements for starting to do SharePoint development and they are introducing a model that will likely lead to users becoming dulled to the need to researching what an App actually does.

Microsoft can’t seem to make up it’s mind. Should we fix our car and modify it now that you’ve made is so easy and accessible for us or should we strive to learn how to properly maintain the engine and not modify it without properly understanding all the consequences of doing so?


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

9 thoughts on “Microsoft’s Mixed Messaging on SharePoint 2013”

  1. Good points, thanks for sharing! SPD design view is really a huge loss and a strange decision from Microsoft 🙁
    However, cannot resist mentioning about the Apps security: they have some kind of sandboxed sites where each app exists, and these isolated sites are meant to be fully secured, so that your app doing whatever-it-wants within it’s own site doesn’t really present any security risk to the main user site (host site), where the user data are stored. Thus, storing scores is ok.

    1. Andrey,

      I think you may have misunderstood what permissions an App requests. It is for the parent web or site (called the host web). It doesn’t need to ask permissions to itself, so when you request an App permission, you do so to the site on which you install the App, not the App itself. The App can blow itself up without asking for permissions 🙂

      Check out the following MSDN article for how this works (and see the note that begins with “An App for SharePoint has its own identity…”)


      1. So you don’t need to request permissions at all to store the scores, right? Since you can store anything inside your app site.
        I understand your point about permissions and I agree in general, but I’m afraid the tetris example doesn’t fit here.

        1. Hang on… Are you arguing whether there are ways to store scores in Tetris that works without asking users for SharePoint permissions? Of course there are, Tetris has worked for decades without SharePoint. That’s hardly the point.

          Does it become easier to understand if I say “Well, let’s say you want to save the score on the site where you installed the App”?

          1. Why would you want to do it? Store the scores on the host site I mean. It’s so impractical and illogical that the idea would never come to my mind.

            Bjørn, I’m just saying that the example is unsuitable here. Just admit it and think out a better one, instead of fussing over nothing here. No offense. Choosing examples is a great skill and I’m sure you possess it – you’ve proved it many times by now.

            Thank you for the post once again, really good points!

          2. Well, I’d want to because I want a department, where each department has their own web site, to have a Tetris tournament and compare scores. It doesn’t really matter, the point is that the permissions are too coarse and you can only request them at install time, which is a great waste of OAuth.

            Here’s another case: I want to provide extended capabilities to users who have Server installed. However, because I can’t install without getting all the permissions I’ll ever need, I can’t install on Foundation without losing the ability to extend capabilities if the client has or later wants to install Server. If I choose to request those capabilities the one time I can, I lose the ability to install on Foundation clients because I can’t request permissions for features that don’t exist. Effectively, this means I need to have two versions of my App, one that targets Server and one that targets Foundation. Then, if the client wants to ‘upgrade’ and utilize the extended capabilities, (and I don’t store data _outside_ the App) they need to uninstall the Foundation version and install the Server version, losing all their App data in the process.


  2. Totally agree about swapping problem set A for B, but the bigger picture is “Whos problems are they?”

    In on premise installations if you did some custom dev that borked stuff its largely your own problem.

    With BPOS/SharePoint online it can easy become Microsoft problem – hence the Sandbox model to attempt to mitigate what can go wrong and keep the damage only in your own area – but we know that didn’t really work.

    With the App model they are attempting to make things safer – but I believe their main concern is ‘the cloud’ and making sure your problems don’t become Microsofts problems.

Leave a Reply

Your email address will not be published.