SharePoint 2013 App Model – The Jury is Back

A few months ago, I stated that I was still on the fence on the SharePoint 2013 App model and that I needed to see more of it to determine whether it is useful. I followed this up with a post titled SharePoint 2013 App Model Solves Non-Problems Only? that have since sparked some debate.

I’m happy to report that the jury is now back and is ready to pass a verdict.

I, the Jury, Find the Defendant Useless!

Let me skip right to the conclusion so you lazy people can just move on. The SharePoint 2013 App model is useless. It isn’t innovative,  it doesn’t offer anything you cannot already do, and its main purpose is as a marketing ploy from Microsoft.

From a technical perspective, I find the App model to be severely lacking even in the most basic functionality. From a user perspective, it is confusing and disappointing. From a developer perspective, it is boring and offers no incentives to adoption.

Finally, and this should interest Microsoft immensely, it is undermining the trust in SharePoint and Microsoft as a serious contender for enterprise functionality.

Now that you’ve read the conclusion, you can sod off and start polluting the interwebs with counter-arguments to demonstrate your lack of understanding.

For those that wish to increase your understanding, read on and I’ll elaborate on why and how I’ve reached this conclusion.

Oh, and you should probably also read the first article on SharePoint 2013 non-problems because it answers some additional points that were clear way back then.

Lack of Innovation

The App model offers a completely new way to build functionality on top of your SharePoint data. Or does it?

The basic premise is that from now on, you should build your Apps outside the SharePoint farm and just call into SharePoint using web services.

But this isn’t really new, is it? For years, those that wish to build functionality this way has been able to do so through libraries like SPServices. Marc Anderson has been a champion of building non-managed code solutions for SharePoint longer than most people have known how to spell SharePoint.

The ‘newness’ has also been argued to be in the vastly expanded functionality that the web services offer and that there are now Microsoft libraries to communicate with these services. Again, this is nothing new, except that the author of the libraries is now Microsoft rather than Marc Anderson.

As for the expanded functionality, this has always been available to anyone who needed that functionality. In fact, even after SharePoint 2013’s release, Microsoft themselves advised customers on how customers could extend the web services with functionality that isn’t included in the App model libraries.

In short, there’s nothing innovative about the model. Everything has been possible all along.

Technical Shortcomings

Even if one were to accept the argument that the concept behind the App model, of putting the calling HTML and JavaScript files somewhere else, is valid, the App model lacks plenty of functionality that is required to build anything but the simplest of solutions.

A typical and recently mitigated example is the lack of ability to create a site collection through the App model. That’s right, up until just recently, there was no way to create a site collection through the App model. It was mitigated on Office365 some time ago, but on-premises clients were relegated to extending the web services on their own. If, for example, you wanted an App to create unique site collections for various projects or teams, which is a pretty common pattern, well, you couldn’t do that.

Note: I’d also like to take this opportunity to point out that this shortcoming wasn’t discovered for almost two years, which should say something about the adoption.

This isn’t the only example either, and a lot of the functionality of SharePoint isn’t and can’t be made available through the App model at all. Examples if this are delegate controls, event receivers, and a range of layout options that cannot be accomplished because of fundamental shortcomings in how Apps work.

So, solutions have to rely on extending the web services themselves. That’s been possible for over a decade already. So what if there’s a new URL you can use to retrieve the data through REST; if you needed that, you could have done so years ago and in some cases you’re still being asked to do so.

Developer Incentives

A key selling point for the App model is that it makes SharePoint development available to anyone who knows how to use HTML and JavaScript. Microsoft has even said that it now has millions of additional developers because anyone with HTML+JS skills is now a SharePoint developer.

The premise of this argument is that through HTML and JavaScript, developers can now access SharePoint data and develop solutions that use SharePoint simply as a data service.

The problem with this is that the App model with its limitations offer very little to incentivize developers to use the platform. At its core, the App model gives you access to SharePoint data, which could have been cool, except that as a data engine for the web, SharePoint isn’t competing.

Note: If you want to look at the competition on data engines for the web, look at Amazon’s range of data services in AWS or even at Azure; all of these offer data engines that far outperform and out-feature SharePoint.

HTML and JavaScript developers look at what features a service provides when deciding where to put their learning and development efforts. That means that SharePoint needs to compete with every other commodity data service.

And it does. Except that the functionality that makes SharePoint competitive such as workflows, delegate controls, master pages, event receivers, and so on still requires farm solutions. That means that to a developer, you either use SharePoint as is, which means it has to compete without any of its unique features, or you still need to learn farm development.

In short, SharePoint as a data service isn’t viable in face of the competition.

User Disappointment

Another key selling point is how easy it would be for users to now implement new functionality in SharePoint. They simply head over to the App store and download the awesome Apps that will improve their work life with a click of a few buttons.

The problem here is that there’s so much you cannot do, many of them high on the list of things users want, that it becomes a disappointment faster than you can convince anyone of the subtle benefits.

Want to create site collections for your teams to manage themselves? Sorry, can’t do that (well, now you can, but it’s taken almost two years).

Want to chance the look and feel of SharePoint (and isn’t that always high on the list)? Sorry, can’t do that.

Want to implement simple functionality to fix things like missing Title fields in documents? Sorry, can’t do that.

I’ve reviewed several business cases for functionality and solutions to be built on top of SharePoint and so far, I’ve always had to either say “Sorry, the App model won’t work” or ask the client to change their requirements because the technology can’t accomplish what’s required. I’ve always been able to say “Well, if you’re OK with using Farm solutions, it can work”.

Users see that what they want to accomplish can’t be done more often than they see that they can get stuff done easily.

Lack of Trust

I’ll probably come back to this point in a separate post later, but Microsoft has painted itself into a corner when it comes to building customer trust.

If you look at the history of the recommended SharePoint solution models, you’ll realize that for every version of SharePoint, Microsoft has changed its recommendation. Microsoft shifts their recommendations so often that it is impossible for organizations to keep up. Organizations and developers put their money and time into a certain and recommended method only to have that method ridiculed or deprecated a few years later.

So, Microsoft, if they were to change their recommendation again for vNext (aka SharePoint 2016), would lose any trace of trust they have. They cannot simply abandon the App model, so they have to stick with it, even if they themselves realize it’s sometimes ridiculous and lacking.

That means they must keep working on getting the App framework to catch up with Farm solutions and that further stifles innovation. They cannot create awesome new functionality that harnesses the power of SharePoint fully because they still haven’t gotten most of the basic functionality to work. And they cannot abandon it because it would kill every ounce of trust they still have in SharePoint as a development platform.

You Are Sentenced to Oblivion

With all these problems with the SharePoint 2013 App model, I’m sorry to say that I don’t really see a future for it at all. Not just that, but the App model is holding back the innovation of SharePoint as a platform; the very thing that made SharePoint so awesome in 2007.

Unfortunately, Microsoft can’t abandon it either; they’ve put too much clout into it. Their entire development story for SharePoint 2013 hinges on the App model, and it’s not telling the story that developers want to hear and it certainly doesn’t tell the story that users want to hear.

It doesn’t matter whether the administrators love not having to deal with farm solutions anymore because, long term, the business solution doesn’t involve SharePoint at all.


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

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!

Read full story Comments { 12 }

On Innovation and How I Wrote SharePoint

After my somewhat public denunciation of SharePoint and prediction about its imminent demise, I’ve had quite a number of talks with people about my passion for SharePoint. Why am I (or was I) so intrigued with SharePoint and what has changed now?

It’s simple really. I wrote it.

You’re probably bright enough that you understand that there’s a longer story behind that, but that’s not really the point of this post. I’m telling you because you need to understand where I come from when I talk about how the innovation in SharePoint has died.

Let me start at the beginning.

You Wrote SharePoint? Yeah, Right!

Well, I didn’t write SharePoint as such; the fine people at Microsoft did that.  What I did write, along with a good friend and brilliant developer named Vegard Berget, was a publishing system called NB2 Publish, that did much of what SharePoint does today.

NB2 Publish was a platform for turning data into content of various types (like… types of content or… content types). It had some pretty amazing features that I still haven’t seen in a lot of modern publishing platforms. For example, the platform supported automatic image optimization so that when you uploaded an image from any format (TIF, PCX, TGA, BMP, GIF, whatever) the platform would automatically convert the image to the optimal format. Of course, automatic resizing and stuff like that was included.

NB2 Publish also supported multi-publishing. What that means is that when you decided to publish something (and there were workflows to do so) you could publish the content to any number of different channels. For example, if you want to launch a new product, you need to produce PDF flyers, update a product database, create a new entry in a carousel, send out emails to your mailing list and so on. All of that is based off the same information, so NB2 Publish allowed you to accomplish all those things in a single operation. If I recall correctly, we even supported faxing at the time.

To support all these different types of publishing, there was also a cool dynamic input system that auto-generated forms for input based on what the various channels needed. For example, if you needed your PDF flyer to have a larger product image, you’d simply update the template used to generate the PDF, and Publish would automatically update the input form and give you a file upload box. It would then make that file available across every channel.

You know, like custom field types work in SharePoint. If they did.

Except NB2 Publish was more awesome because it took the reverse approach to the dynamic typing problem in SharePoint. Rather than depending on the user maintaining a correct list of field names and then telling the target that “here’s the information available, if you’re missing something, tough luck”, NB2 Publish would instead ask “What information is required to accomplish this task” and ask the user to provide that. No risk of field corruption; if you screwed up, the user would simply be asked for the additional data rather than the whole system crashing or you having to rewrite your entire database just because you hadn’t planned for that one feature the user requested.

The NB2 part? Well, that was mainly a development framework in which we had built our own scripting language (which we later found out was actually Lisp, or at least a related language). Heck, in later versions, we even had remote support, somewhat similar to web services, so you could call into the publish engine from any programming language that could send text over the wire.

We even had remote scripting support and that didn’t mean what you think it means. Imagine if you can write a program that sends off parts of itself to be executed on another server. Multi-threading would never be the same. Now, every computer connected to the internet, and being able to run NB2, would be one massive computer to which you could send instructions for execution and get results back.

- How many cores did you say you had?

- I don’t know, how many computers are there on the internet?

All in all, it was a pretty awesome product. Sure, it wasn’t nearly as fast and the code base was… Let’s call it interesting for lack of a better word. It lacked a lot of the bells and whistles, but we knew how to do amazing things with the platform and the framework.

And, here’s the kicker: We wrote this in 2000. Yup, years before SharePoint saw the light of day and even before .NET made remote web services a reality, we had all that. We had safe and stable dynamic languages that was so easy to use we trained our secretary to build templates for customers (she was smart, but maybe not computer smart). We had content types, list and document repositories, automatic PDF creation, email alerts, custom field types, workflows… The lot. Plus more.

Now, you’ve never heard about NB2 or NB2 Publish (unless you worked for or were a customer of the company whose name is now tattooed on my left arm) and you’re probably not going to believe any of this. That’s fine, I’m not here to convince you of anything, but if you’re capable of either reading Norwegian or can use Google Translate, you can read a lot more information about NB2 and NB2 Publish at’s repository of

Note: You may also, with some sleuthing, realize we also wrote Google Analytics in 2001. It was called Stics and I’m not giving you more hints.

You’ve never heard of any of this because at the time, we were a very small software shop. In fact, with a few and very valuable exceptions, Vegard and I were the only developers there. That leads me to why I was passionate about SharePoint.

Innovation is Such a Lonely Word

You see, the company, or companies, that owned NB2 and NB2 Publish eventually went bankrupt. They died out. That was largely because Vegard and I tried to take over everything and be both business people, sales people, support people, marketing people, developers, administrators, janitors, secretaries, and whatever else we needed done.

I don’t even have the code still. Benny Samuelsen at ISPHuset, who purchased the remains of the last company may have a copy somewhere, but I don’t.

When I saw SharePoint 2007, however, I saw some of the same features or at least the same ideas implemented by a huge company. The ideas were there if the execution wasn’t quite the same. Perhaps then, Microsoft could pick up where our dreams and products had failed, and I could just ride the 9:30 innovation express from Redmond to bliss.

So, I started doing SharePoint because it was innovative. It had the right ideas.  It was awesome.

SharePoint still is awesome, but the big, big problem is that it is exactly as awesome as it was in 2007. Not more awesome, not less; just as much. That’s because there hasn’t really been any innovation on the platform. The things that sparked my interest in 2007 haven’t changed. They haven’t been driven forward.

Note that I’m saying “the platform” here. I don’t care about SharePoint the product. That’s boring, predictable, and stale, and that includes Office365.

That’s a bit sad because there’s so much stuff that can be done with SharePoint still to make it even more awesome. That had nothing to do with putting more bells, whistles, and colors on it. It has to fundamentally change the way organizations think about data.

SharePoint 2007 blew everyone’s mind. Behind the scenes, everyone who could tie their own shoelaces saw the potential. I still get erotically aroused when I think about content types. The disconnect between SharePoint the engine and the UI is brilliant. That’s when Microsoft laid the foundation of SharePoint’s success.

Yeah, there’s a disconnect between SharePoint the engine and the UI. In 2007. You know, what’s now being hailed as “the most awesome thing since sliced bread” and “newer than an infant with birth goo on it”. It has been there since 2007. You just haven’t seen it, likely because you’ve been too busy crucifying those that do see it.

Then, in SharePoint 2010, Microsoft fixed some of the issues and created a more polished product. It wasn’t very innovative but it was more stable, except in the parts that were completely new and most of the SharePoint Server crap. SharePoint 2010 was really a version 2 of SharePoint 2007. It wasn’t a new product; it was just a much improved version of the same product.

But in SharePoint 2013, there’s nothing. It’s not better in any way. It’s far worse. It’s less stable, it runs slower, requires far more hardware even with that lower performance, and there’s nothing, absolutely nothing new. There are a few new apps on top of SharePoint, but in SharePoint itself, innovation has just stopped.

You see, the bones that get thrown to the community isn’t innovation; it’s marketing. The world has thought of all of this before. I know, because I did it myself, and I just plainly assume that means a lot of other people have done so too.

Imagine, when two kids in a small rural town in backwards Norway could create NB2 Publish, doing pretty much everything SharePoint does and more in two years, what Microsoft could create if they were truly innovative. There wouldn’t be a competitor to SharePoint ever. Microsoft would be decades ahead.

Instead, they suck the motivation out of the community and hope that you all bite and get distracted like the puppies Redmond wants you to be. Then, they use your distraction to suck as much money out of their customers as possible. And they lose the race to have great platforms.

Microsoft has one more chance to be great again with SharePoint 2016. If they fail, and you can start realizing they are when you see buzzwords like Social Enterprise Cloud and other terms from the BS Bingo, then some kid in a rural town somewhere in Scandinavia will launch the next thing that just obliterates SharePoint.

And you know… You’ll still be a SharePoint professional at that time and go down with it.

Thanks for reading,


Read full story Comments { 2 }

Why Dynamic Typing in SharePoint is Suicide

I was browsing through Glyma today and noticed a comment on my own blog that requires some… explanation. As usual, the poster is an idiot, or at least makes an idiotic comment, but before we get there, a few things need clarification.


Yeah, you see, there’s this guy, Paul Culmsee, who is beyond awesome. He’s the guy that got me started writing and now, 20+ books later, I still find myself wondering if I’ll ever compare to Paul’s writing. 

In any case, his company has come out with this brand new thing called Glyma which I guess is a tool for mind mapping or dialogue mapping or whatever it is called. I don’t know too much about these things or its terminology, but I know one thing: It’s frigging awesome!

What it does is basically create a tree of knowledge (and no, you religious nutcases, not that kind of tree of knowledge) where you can refine information and knowledge down to its minute detail. I find myself browsing through the trees already created to explore ideas, review content, and most of all, laugh at some of the knowledge. And no, that’s not always the good kind of laughter either.

I’ll most likely come back to Glyma in far more detail, but for now, I want to point out one particular topic.

Note: You can check out Glyma yourself at But don’t do it right now or you’ll never come back here to hear how to save yourself from embarrassment in a discussion on dynamic typing in SharePoint.

The topic in question is on how awesome SharePoint 2013 must be because it uses all the cool features of .NET 4.0 such as dynamic typing.

Dynamic Typing?

You may not know the innards of programming, but basically, there’s a somewhat religious debate regarding a topic called typing, of which there are two types, pun intended: static/strong and dynamic/weak.

Certain languages are dynamically typed by default, such as JavaScript, Perl, and to some extent and very optional, C#.

The difference may seem subtle but is very important in building stable systems. This fact seems to elude proponents of dynamic typing.

Essentially a statically typed language will make sure before you can even complete writing a piece of code that any properties or fields exist. A dynamic language couldn’t care less.

For example, let’s say you have an invoicing application in SharePoint with an item called Invoice that has a field called DueDate.

In a statically typed language, you cannot complete the writing of code if you mistype DueDate (for example if you write Duedate or dueDate) or if you write DueDate but the field does not exist. So, in a statically typed language it is impossible to misspell field names because your code will simply not run.

In a dynamically typed language, however, you have no idea whether the field exist when you write the code. If you misspell something, you won’t find out until your code breaks, which can happen at any point from now and until the sun blows up.

SharePoint in Particular

The particular comment in question is to my post on how SharePoint 2013 Apps Solve Non-Problems Only, readily available from your local search engine. The comment points out that only the .NET 4.0 runtime, which is available only in SharePoint 2013, supports dynamic typing and that users that want to target older SharePoint version misses out on that awesomeness.

[…]the dynamic keyword (dynamic would have been awesome in dealing with list item columns, a little puppy dies every time someone codes item["ColumnName"].ToString()). Always felt stuck in the past doing SharePoint 2010 development.

SharePoint encourages users to change their data so you may think that dynamic typing is an awesome idea. After all, what if you want to change your field names around? You may think that Duedate just looks better than DueDate so being dynamic must be great, right?


You see, dynamic typing, which is the stuff offered by the dynamic keyword, doesn’t actually change the code. It just ignores checking to see if you’ve written it correctly. If the user changes the field name from DueDate to Duedate, the code will still run; it will just fail or cause unwanted effects. You may not notice that because, you know, your developers ignore such mistakes on purpose because they’re lazy. Or stupid. Or Both.

I’m Not Lazy! Static Typing is Just As Bad!

Static typing won’t save you from users changing the names of fields. It won’t even save you, really, from misspelling of names. Like the commenter pointed out, it’s possible to write stuff like item[“Duedate”].ToString() (which turns the value of the field named Duedate into a piece of text). That’s because the “Duedate” part isn’t strongly typed.

That’s why you don’t rely on dynamic typing at all. Only an obtuse idiot or complete newbie would write item[“Duedate”] because if someone changes the field name, and that is supposed to happen, the code breaks, just like if you use the fancy new .NET 4.0 features and type item.Duedate instead.

The latter is just as bad, at least in SharePoint. It kinda works in other frameworks where field or property names aren’t changed, though. It’s still lazy.

Instead, real developers with proper understanding of problems such as this knows that you  rely on fixed or static properties of fields if there is a chance that non-fixed properties can change. Nothing dynamic. Fixed is reliable, stable, and dependable. Dynamic is not. Dynamic is lazy and unstable and takes away your freedom to change your field names.

Luckily, the Microsoft developers are usually good developers and know about simple problems like this. They have, completely free of charge, given you several fixed and static properties with which you can work as a developer. The InternalName property is my favorite and regardless of what the user does with regards to changing the display name of a field, the InternalName does not change. From the InternalName you can find the dynamic name reliably, but you can’t do it the other way around.

The point is that the dynamic keyword in .NET 4.0 isn’t useful in SharePoint at all. You still need to do exactly the same thing in .NET 4.0 as in .NET 2.0 to ensure your code is stable and reliable because, you know, SharePoint is quite independent of such things as fancy syntactic sugar or lazy developers.

Note: With the influx of newbie JavaScript developers and conversion of possibly decent SharePoint developers to SharePoint 2013 App JavaScript nutjobs, I’m expecting a ton of Item.DueDate code in the future because, you know, it’s more important to hang with the cool kids than to understand your job.

This, by the way, is somewhat of the same problem with content types. Newbie developers will reference content types by their names for example if they want to add columns to the Item content type. You can see this if you ever see SharePoint code anywhere that looks like ContentTypes[“Item”].FieldLinks….

If that’s the case, and you see such code in what your developer hands you, take that developer out back and beat them over the head until they can tell you why that is a stupid idea (and I’ve been beat over the head enough that you don’t have to point out that I’ve done this error in the past).


Read full story Comments { 2 }