In this weekly blog I’ll discuss SharePoint development topics related to the current state of SharePoint, updates we see coming down the road, how SharePoint and mobile technologies can work well together, interesting tips and tricks I find during real-world projects, and reader-submitted topic suggestions.

As you will see in this blog, I take a pragmatic approach to SharePoint solution architecture and development.  If you have a suggestion for a future blog post, please let me know about it in the comments section at the bottom of the page.

To start things off, I’d like to chat about what it takes to be a SharePoint developer in 2013.  This topic was suggested to me by Caroline Marwitz, who edits the content you see here on SharePoint Pro.

Caroline mentioned that many readers have been asking questions like “What do I need to do to be a successful SharePoint developer now, and in the future?” and “What’s different in SharePoint 2013 development?”

Before I go on to answer those questions, let’s take a step back and look at the bigger picture of SharePoint and how the product is changing right before our eyes.

AM I HAVING A FLASHBACK?

SharePoint 2013 reminds me of SharePoint 2003.  Now you might be saying, ‘What are you talking about, Todd?!” Let me explain.

When SharePoint 2003 was released, it was built on a new platform (.Net), its architecture was different than previous versions, not many people had expertise with it, developer documentation and tooling was limited (or should I say, almost non-existent), and one had to fundamentally change the way they thought about SharePoint architecture and development to properly implement the new version.

As subsequent versions of SharePoint were released some changes were introduced, but none of them as fundamental as the changes we saw between the first version of SharePoint, and its successor, SharePoint 2003.

As new versions of SharePoint were introduced (2007, 2010), the core SharePoint framework was improved upon and eventually we got to the point where there was plenty of documentation, robust tooling support, and an immense amount of community support.

I can remember when my SharePoint blog was one of about a dozen on the planet; now there are probably thousands.

All this being said, in a general sense, with the exception of a few things like Sandbox Solutions, Web Templates, and some things related to service applications, core SharePoint development did not change a whole lot and many of the patterns we used in 2003 could be tweaked and applied to subsequent versions.

For example, the SCHEMA.XML file defines a list in all versions of SharePoint and although we edited SCHEMA.XML file with a text editor in 2003, eventually we were able to do so with Visual Studio project templates and items.

As we look at SharePoint 2013, some of these points still apply to one degree or another.  For example, instead of re-platforming on the .Net Framework, SharePoint 2013 introduces the new SharePoint App model, designed to work in a more distributed, cloud environment.

Developer documentation is much better than it was in 2003, yet the immaturity of the SharePoint App model reveals gaps in documentation which the MSDN team is constantly working to fill.

Tooling support is much improved from the 2003 version of SharePoint, yet there still are some gaps related to the SharePoint App model which the Visual Studio team is also working hard to fill.

As subsequent versions of SharePoint 2013 are released, we’re going to be seeing many of the same things that occurred after the 2003 release.  You can count on seeing the new SharePoint App model, the APIs that support it, and the documentation and tooling improve.

There will be some changes that come in the future related to the product as it evolves along with the basic tenants that support it, such as cloud computing, security, and distributed line of business solutions.  It’s the nature of software and how software products evolve over time and this version of SharePoint will be no different.

At the end of the day, understanding how the product evolves and staying on top of the changes will be very important to ensure you can properly architect and develop a SharePoint solution.  This key point illustrates how people became successful SharePoint architects and developers in past versions and that won’t change in the future.

Now that I’ve explained the similarities between SharePoint 2003 and SharePoint 2013, we have some context to apply to as we discuss the questions I mentioned before.

WHAT DO I NEED TO DO TO BE A SUCCESSFUL SHAREPOINT DEVELOPER NOW AND IN THE FUTURE?

To be a successful developer with SharePoint 2013 and the versions to come, you’re going to need to learn some slightly different skillsets than you did for past versions of SharePoint.

However, many of the skillsets applicable to SharePoint development in past versions are still required.  In the past, the following skillsets were required: .Net, ASP.Net, HTML, JavaScript, CSS, and they still are today.

Some of the new skillsets you’re going to need for SharePoint 2013 include OAuth, Azure, and understanding the new SharePoint App model.

Although there are new skillsets required for SharePoint 2013 development with the new SharePoint App model, many things that made a good SharePoint developer in past versions stay exactly the same.

These things include knowing what resources are available to you as a developer, your professional network, and the proper developer mindset.  There are many great resources you can draw upon to help you learn how to do SharePoint 2013 development.

WHAT’S DIFFERENT IN SHAREPOINT 2013 DEVELOPMENT?

The main difference between developing for SharePoint 2013 and previous versions of SharePoint is the new SharePoint App model.  As I’ve mentioned before, the new SharePoint App model is designed for distributed systems, particularly in a cloud environment.

Not only does this new app model introduce new technologies a SharePoint developer must master, but it also requires you as a developer to shift your mindset to think about how to extend your SharePoint applications beyond the traditional server side SharePoint environment and incorporate components that run on systems outside of SharePoint.  A Provider-hosted SharePoint application is a perfect example.

Other things that differ, which should definitely be considered, are the new cloud-based platform many SharePoint 2013 solutions run on and the processes associated with development and deployment that go along with it.

For example, when defining the architecture for a SharePoint application that runs on an Office 365 SharePoint site, you should take into account the fact that O365 tenancies are continually upgraded as the product evolves.

The O365 service upgrades might include API, HTML, CSS, or other changes that could break an application deployed to a prior version of a given tenancy.

To work around this, think about how to prevent these changes from crashing your custom applications and how to ensure you are notified when your tenancy is upgraded, so you can test your applications to ensure they work properly with the newer version of your tenancy.

Hope you enjoyed reading it.

Please don't forget to Share, Follow and Like to get updated with latest posts.

It gives me motivation to share more knowledge with you.

About Author

Satyendra Mishra

Project Management Professional (PMP) and Microsoft certified, motivated, energetic and accomplished Project Manager / Architect with 15+ years of work experience in Management, Architecture, Analytics, Development and Maintenance. I have been fortunate to be a part of over 25+ .Net / SharePoint projects delivery with various companies across different industry sectors. This has provided me a valuable insight and experience especially in successful implementation of SharePoint based solutions.

My experience in Web application implementation includes technology strategy and road-map definition, business and technical requirements identification, governance, platform architecture, solution design, configuration, development, quality assurance, training, post-production support, team lead and overall project delivery along with project management.

Satyendra Mishra holds a B.Tech. in Computer Science & Engineering and PG Diploma in Advance Computing from Center for Development and Advance Computing, Pune, India. He is also a certified Project Management Professional (PMP).

I love to share Project Management Tips and Tricks by writing Blogs in the Project Management India Community. I have written around 300+ articles in the Project Management, .Net, SharePoint and related client side technologies.