This has been a question that I have been trying to figure out for a while. Any good SharePoint Developer will tell you that writing a Solution File (WSP) full of components is relatively straight forward and easy to manage. It has become easier and easier over the past few releases of SharePoint as more and more people have joined into developing solutions.

I remember back in the day when SharePoint didn’t have a Solution mechanism at all, I also remember how hard it was to get my head round how to build solutions, as it kind of matched what I already knew about developing projects in Visual Studio but not really. I look back over that time and realize that in reality it just took time for this approach to work. Now I can ask any of the Developers I work with to build solutions and they are know how to do it, the nuances that are now well known, along with the best structure that works.

And then it happened?

With this last product release and of course Office 365, the idea of writing full-trust code almost became a “bad thing“. Almost seemed like you had to whisper or use secret signs to tell people you were still doing full-trust code. Even then you almost got a “look of disgust” that you were not doing things the new way, the better way, wait a minute the unproven way. Did we forget that?

Using client side code to perform functions within SharePoint has been there for a while and works great, just grab the “SPServices” project that Marc Anderson has worked on tirelessly for years and see for yourselves. Creating isolated code that does not run within the “w3wp” process has been around a while too, though limited worked well for some solutions. So if all of this is already here, why is so much stigma around what you should and shouldn’t do?

That is the fault of the word “Cloud“. Since this word had its meaning changed from the white fluffy things in the sky to mean a bunch of servers and services hosted by someone else, everything changed.

So what is all the fuss about then?

The core issue is that we a people and users of technology now expect greater availability of services than ever before. I remember back in the day you could turn off the email servers for hours and days and no-one would care, now if it doesn’t work for a few minutes we end up sitting in the corner rocking backwards and forwards. On a serious not that is why things have to change.

We have to build better solutions, often more complicated and more “moving –part” solutions because the infrastructure that once sat under the IT Admin’s desk is now servers and services hosted on a massive shared platform where we don’t have the core Admin or Root access we all used to have.

So back to my original question; how do you sell the new App Model to SharePoint Developers?

The answer is really simple, YOU DON’T. As existing clients move from on-premises environments to the cloud, Developers will naturally have to start architecting and developing solutions that can work in both. If they do not, then when the client decides to be “all-in” on the cloud, it will be painful task to convert or re-write everything to make it work.

We have a great stack that we can use to build solutions today that even though they are on-premises, will be easier to migrate to the cloud when needed. In an ideal world we would all stop developing “Full-Trust” solutions even for on-premises environment and build using the new App Model so we could almost overnight move the code to where it needed to be.

You know as much as me though, that doesn’t happen, because we know what we know, and we are comfortable building what we know. Also there are still some things that just don’t work when not in “Full-Trust“, but remember this list is getting smaller by the day it seems.

So aside from brainwashing the Developers, beating them into submission or threating to fire them unless they build Apps, we simply need to watch and wait and the change will happen. What we do have though to help us is a big marketing engine that is ensuring this change is coming sooner than later. More and more of the clients I work with are almost “Cloud” ready, a few more things that need changing and then I can see a lot of them jumping to the cloud in whatever form that is. I can see more and more client moving their SharePoint environments to Office 365, purely based on ease of management and supportability.

However we are not all there yet, and as such “Full-Trust” for on-premises is still a go, with a few tweaks to the way you develop them you can be happy that the migration later will be less painful. Until someone creates a tool that can import your WSP, and re-create it as an App you we will always have to re-work.

To help the Developers out I recommend heading over to http://dev.office.com/ and look through the samples that are there. Going here http://dev.office.com/code-samples and filtering to “Apps for SharePoint” will give you great examples of what other developers and Microsoft have done. This should help in choosing whether the next solution should be “Full-Trust” or “App” Code.

As a person who likes servers to run happily and as much I often enjoy trying to figure weird stuff out, I would rather not trawl through endless ULS logs or read through code to see what the “Full-Trust” code is doing wrong. If I can advocate moving code from the servers then that is a great motive to build “App” now.

My message to all SharePoint Developers is to embrace the “App Model“, come to like it, won’t say “LOVE IT“, don’t think anyone loves writing SharePoint Code (just kidding). Study the samples, walk through the code over in the “Patterns and Practices” repository (https://github.com/officedev/PnP) and write your first “App“!!

The “App Model and Cloud Train” is moving quickly, and will continue to move with or without us.