The State of SharePoint Development: 12-Year Veterans Take

I’m a web developer, not a SharePoint developer…

So, I have been sitting on this for a while. I get that there are plenty of people who will not agree with my opinions I put forth here and that’s fine… to each their own. As someone who has been in the SharePoint space for nearly twelve (12) years now (yup, I started in September 2003), I believe I have a fair grasp of where we have been and where we are as far as it relates to developers in the SharePoint space.

When I talk to customers today, this is what I say. Those close to me and most people who I’ve worked with over the last year or so have heard me say it. Some of those who’ve attended recent conference talks I’ve done have heard it. I am not posting this to refute anyone or anything… I just feel like we are long, long overdue to adopt this approach.

TL;DR

It’s long overdue for many of the SharePoint developers who keep complaining about the state of developing and extensibility that the app / add-in model sold as the successor to solution-based development to move on. The sooner these developers embrace that the present day SharePoint, regardless if it is on-premises or hosted in Office 365, is a service and not a development platform, the better development life gets and the quicker you move on.

Stop building stuff that is deployed into SharePoint and stop trying to change the way it works. The more you try, the more frustrated you get and the less success you have. Plus, one day, something will change and your stuff will break and everyone will have some great flame war again.

Microsoft wants this to be a service… the sooner you accept that and move on the easier things get and the more you’ll accomplish. Put all of your stuff either 100% outside of SharePoint, or 100% inside SharePoint as a single atomic unit (such as a SharePoint Hosted Add-in or use their client web part / IFrame or DIV model.

Stop trying to change the SharePoint experience… take it for what it is.

Let Me Explain Myself…

For so many years SharePoint was pitched by Microsoft as a development platform. It wasn’t just Microsoft… many of us have been saying it including yours truly. I thought what better thing to build applications on when so much stuff I needed in a custom application. I needed navigation components, security, a way to store data in tabular format, search… so much stuff was right there for me in SharePoint!

All we had to do was build a custom application and deploy it into the SharePoint process. At first we did this manually (2003 - 2007) with a lot of hand wringing in SharePoint 2003. Then (2007) we got a way to package up our customizations and put them on the server in SharePoint 2007 when we got features & solutions.

You could do so much stuff with this approach! We could create custom timer jobs to have scheduled processes run, we could create pages with fully trusted code beside / behind files, we could alter the navigation and even create administration pages (aka: application pages). We could really bend SharePoint in every different way.

Ah… the golden days to many of us… business was great, there was tons of work and everyone was hiring. SharePoint was blowing up in a good way… we were in the booming years. I promoted this every chance I got. I spoke about it at conferences, wrote about it in articles and blogged a ton about it… the evidence in the archives of this blog!

Before you read on and say “wait a minute… now you’re telling me something totally opposite than what you told me a few years ago!”
You bet I am. Times change… things change… we learn from our experiences, environmental changes around us and we adjust our thinking. I most certainly have. The best we can do is to simply take all experience and the current information at hand and make the best decisions at the time. That’s what I’m doing now and what I did back then as well.

All Of This Came With a Cost

It was around this time (2007-2009) that we started to see people try to implement testing to our custom solutions… and we were never fully successful. Many developers figured out ways to get their code tested to certain degrees of coverage, but never fully because SharePoint’s API was such a black box. Some also tried to implement application life-cycle management (ALM) processes and continuous integration (CI) into SharePoint development. I’m not saying it isn’t impossible… it definitely is… but it takes a lot, a whole hell of a lot, of effort to set up and maintain.

When Microsoft would get support requests for a customer’s SharePoint environment being down, guess what the root cause was for these outages the vast majority of the time? Custom code… us… the stuff we wrote… many times stuff we wrote that was promoted by everyone out there. From Microsoft to MCS to folks like me and your peers.

In addition Microsoft started to work on Office 365, their plan to host SharePoint (among other services) on their own. Why? Only they can give you the exact answer but from my perspective it was partly to get in the services business and out of the every-three-year-release business, partly to tap the small business market who couldn’t afford SharePoint’s huge up front capital expense, and partly to offer a product / service where customers didn’t have to maintain their own SharePoint deployments which was expensive.

So Microsoft Introduces Another Model

So Microsoft introduced a new development model, sandboxed solutions, (2010) where our code was isolated from the rest of SharePoint. Unfortunately this model was too isolating and limiting for server side code. However sandboxed solutions are still around today and are fully supported when they are entirely declarative quite useful in many scenarios. Even so, many customers took a pass on sandboxed solutions and even Microsoft does not exactly recommend them anymore.

So Microsoft Introduces Another Model, The Sequel

Starting to sound like a Monty Python script eh? That one fell into the swamp. So I built another one… that one also fell into the swamp. That one burned down, fell over and then sank into the swamp. But the fourth one stood!. I guess that’s true until we get the next development model for SharePoint…

At this point now Microsoft has come to the conclusion that solution based development (farm / fully trusted or sandboxed / partially trusted) is not the way to go. Instead, we should be building things that run external to SharePoint. So this time (2013) they introduced yet another development model for SharePoint called the Add-in Model (originally called the App Model, but renamed in mid 2015). This is what we have today. We can build add-ins that live either within an isolated site in SharePoint (aka: SharePoint Hosted Add-ins) or one that lives external in some other place (aka: Cloud / Provider Hosted Add-ins) and communicates with SharePoint over HTTPS with REST APIs and is secured using OAuth 2.0. Actually there was a third option, Auto Hosted Add-ins, but that was ultimately discontinued and taken away leaving us with just the two options.

The problem with the current model is there are still plenty of options where we can stick our fingers in SharePoint and tweak things like customizing master pages, CSS, injecting JavaScript in the pages (a questionable security practice at best)…

Great Story… Where Are We Today?

Notice a trend? Over time the development models have tried to move developers further and further away from building INSIDE SharePoint and instead are trying to get us to build our customizations OUTSIDE or BESIDE SharePoint. There are two problems that I see with this though:

There are still way too many places where the current models provided in one sense tell us to get our customizations out of SharePoint, yet there are others where it is still encouraged with things like JSLink & custom CSS. You can’t have your cake & eat it too.
People are trying to map their old customizations they did with fully trusted solutions to the add-in model. In fact there’s a whole project and body of work around it… it’s called Patterns & Practices by OfficeDev. You can’t take a philosophical direction you want to take a product & expect you can do the same things you did before, expecting different results.

And who’s to say we won’t get yet another development / extensibility model in SharePoint? The track record of Microsoft releasing yet another model isn’t exactly that great… or in reality it’s pretty consistent; we get a new model with each new release of the product. I’m not saying we’ll get one with SharePoint 2016… in fact I doubt we would. But in the next few years? Wouldn’t shock me… it would disappoint me, but not surprise me. Customers already dismiss the add-in model… I don’t see many people using it today. There’s a lot of talk around it, but in reality, I bet Microsoft wouldn’t want to admit how many people have built add-ins and deploy them to SharePoint Online in Office 365. Another model would be dismissed even quicker.

Which Brings Me To My Take on SharePoint, or not-SharePoint Development

From where I stand, it’s blatantly obvious where Microsoft wants to go with SharePoint & Office 365 as a whole. SharePoint is a service, just like Exchange or Salesforce or Outlook.com or GMAIL or GitHub. They want to provide a service that people subscribe to. Yes there’s that on-premises offering that they can’t get away from because there are so many customers who bought into massive deployments and have put so much of their data in it that there are very real challenges to moving to the cloud including regulatory or legal reasons… Microsoft would be a fool to walk away from that huge revenue stream… but it’s clear where they want to take the product. Office 365 is leading the innovation as far as SharePoint is concerned… on-premises SharePoint is simply a snapshot of where SharePoint is in Office 365 at some point (yes, I know that’s a bit of an over simplification, but you get the idea).

To make this direction work with the product, to innovate and update the product on their schedule to bring the best features & capabilities to their customers, they need to have control over it and that means getting developers out of the product. Sure, they give plenty of ways to get to your data and the services SharePoint has to provide. That’s why you see so much innovation and work going on in the API space. In the last year we have seen a TON of investments and releases around Microsoft Entra ID and APIs from Office 365 (Exchange, video portal, Office graph, groups, OneNote, OneDrive, etc.) and Microsoft as a whole (the Microsoft Graph / Unified API).

I watch peers in this business who continue to try to customize SharePoint and deploy their customizations into the product like injecting things in the host web or customize the master page and the like get constantly burned over and over by some change to Office 365 that negates / breaks / alters their customizations. This just seems like a constant cat & mouse game. So I take the approach that it’s just not worth the effort to do SharePoint development anymore. Instead, build your stuff separate & isolated from SharePoint. Maybe that means a web app running somewhere in Azure or in IIS on your corporate environment that communicates with Office 365 or SharePoint through the various APIs, secured behind AzureAD. Maybe it’s a single page app that is deployed to an AppWeb using the SharePoint Hosted Add-in model.

In essence, work the same way so many other modern cloud products work. You don’t inject your applications into Facebook and for the most part you don’t inject them into Salesforce. Instead you register your application with them & communicate to them using their REST APIs over HTTPS.

What conversation am I having with customers? I spend a fair amount of my time mentoring or helping development managers and stake holders in their SharePoint / Office 365 deployments come up with a plan.

Since the start of the year, I tell them don’t do SharePoint development. Don’t try to customize SharePoint. Maybe create a theme or composed look to change some UX a bit, but don’t build scripts to deploy using JSLink in the host web. If you want it to live inside SharePoint, then make it live inside SharePoint with an AppWeb and using something like Angular. Don’t like the client-side development world? Fine… then stay with your server-side code and build ASP.NET MVC or Node.js or use whatever technology you want, just don’t put it in SharePoint… put it outside. Don’t register it as a provider hosted app… use the AzureAD application model to grant your application permissions.

This conversation usually goes quite well. Sure there are some who dig their heels in and want to execute their vision. There are some stake holders who are frankly afraid to go back and do a 180 on their investments like this for fear of what the company will think. But business has changed over the years (many years, not just the last year or two) and from where I sit, this is the safest, most future-proof, most productive and efficient way forward. You are essentially isolating yourself from any changes with the product… either your application or changes Microsoft does to Office 365 & SharePoint Online or SharePoint on-premises.

There will always be someone, I’m sure they’ll show up in the comments of this post, that say “yeah but my project needs me to build {x} and I need to use a solution or inject this script in the host web” where that {x} could be something like a timer job. You know… I hear you… but when I hear that while you need to listen and judge each thing based on the requirements and what is available to you, I go at it with the attitude of “maybe you’re trying to do something that you shouldn’t be doing in SharePoint.”

I really like this approach. As a developer I’m freed up to use the best tools & practices available… not what fits into SharePoint. Life is better as a web developer… setting up testing, continuous integration, automated deployments… all this is so much easier when you take SharePoint out of the picture.

Closing

If you’ve read this far, first thank you!

I’m sure there will be plenty of people who dismiss this and say I’m way off base. That’s fine… this is my opinion and perspective. It’s based on 12 years of doing this. Like I said above, I acknowledge that this is a 180-degree flip from many of the things I’ve said over the years with respect to SharePoint development.

Let’s have a conversation… there’s a comment box at the bottom of this post (yes it’s moderated just to keep the trolls, spammers & flamers out… let’s get some healthy discussion, agreement & disagreement going!).

Maybe now you see why I say…