Mobile First, Cloud First” is the new Microsoft mantra. You can’t read anything about their strategy under new leader Satya Nadella without reading or hearing those words.

A large part of this “Mobile First, Cloud First” world is Office 365. Now, for several dollars a month, the common man (or woman) has access to Exchange, Lync, Office Web Apps (reading and editing Office applications in Web browsers), Yammer, up to 1TB of personal storage with OneDrive, and SharePoint Online.

For small and medium-sized businesses, the move to Office 365 is pretty much a no-brainer. As we see more and more companies adopt Office 365, and as more and more enterprise customers start to dip their toes in the cloud, we as developers need to make sure we have the tools necessary to help these organizations succeed in their endeavors. So, what does all of this mean from a development perspective?

The SharePoint story
Today, a large portion of the customizations and application development we do in Office 365 will be for SharePoint. I could hear your groan as I typed that, but it’s true. SharePoint Online is an important piece of the Office 365 puzzle for businesses. If you’ve had to do SharePoint development in the past, you know what a frustrating experience it can be. Guess what? Now you get to learn even more because Microsoft has decided to change things up. Maybe this will make more sense after I tell you a little story.

SharePoint development has come a long way over the years, but at its core it has mostly consisted of developing assemblies in Visual Studio and copying those assemblies to your SharePoint servers. In the very old days, this was a manual process, but as SharePoint matured and the tooling got better, a lot of these processes became automated. Developers no longer had to create their own manifest.xml files or manually copy DLLs to your servers. Things got better. The creation of a Web Part became as simple as creating a new project in Visual Studio, writing a few lines of .NET code, and letting some administrator who understands PowerShell deploy the solution. More developers were creating solutions.

In some ways, it became too easy to develop solutions for SharePoint. With a lower barrier to development, many developers were creating very bad solutions that ate away resources, performed poorly, and caused farms to crash. Because many developers didn’t take the time to learn SharePoint, there were a lot of poorly written solutions being deployed to their SharePoint farms. What’s more, these poorly written solutions had full access to everything on those servers.

How many times have you heard a user complain about performance in SharePoint? How many times has a SharePoint user griped that the site keeps breaking? Most of the time the reasons for these complaints come from an uneducated developer. Let’s face it: One of the reasons consultants like me have jobs is because so many people were doing a bad job at SharePoint development.

And this is how things were. Those who were good at SharePoint development were very good and could develop really powerful functionality in very little time. The possibilities were endless!