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