Maybe you are an aspiring SharePoint developer who needs to understand what you’re going to face as a SharePoint developer. Or perhaps you’re a business user, a project manager for example, looking to understand where all your money goes. Or you may just be here for the free t-shirt, in which case you will be very disappointed.
SharePoint development is far from normal development. So, exactly what makes us SharePoint developers so special?
First, there’s the skills requirement. SharePoint developers need to master a range of skills so great, it will make quantum mechanics seem like Spelling 101.
Second, traditional development methods and experience will only get you a fraction of the way. Unit testing, for example, is useful only for the first few hundred lines of code, after which it becomes more of a burden than an asset.
Third, we are not the only developers of a solution. In fact, the better a solution we make, the more developers (whom we don’t know) will develop our solutions.
All in all, we are shooting at a moving target while wearing blindfolds, without knowing what the target looks like, where it is, or what type of ammo we need to use. In fact, we don’t even know if we’re in the right shooting range.
Skills requirement
SharePoint development is completely different than other forms of development in that it covers such a wide range of tiers and technologies. As a developer, you need to be proficient in the first tier of development, which mainly consists of customizing a solution through the Web interface, or out-of-the-box customization, as it is often called.
Then you need to understand the extensibility through the middle tier, in which you utilize scripting and markup languages such as jQuery, JavaScript, XML, XSL and so on, usually done through tools such as Microsoft’s SharePoint Designer.
Finally, you have the third tier of development where the programmers reside, and most of your work will be done using tools such as Visual Studio and Notepad. If the end result is a SharePoint solution file, or a .WSP that needs deployment documentation and someone versatile in PowerShell to deploy, chances are high that you’re doing third-tier development.
Oh, and don’t think that just because you dream in .NET MSIL that you know about SharePoint development, because even for a die-hard third-tier programmer, there are so many technologies you need to master. Of course, there are all varieties of .NET, but you need to speak XML to your family at dinners, and you should be fluent in the XML dialects that SharePoint uses. Further, there’s a need to understand all the levels and intricacies of the SharePoint object models, both the server object model and now the client object model. Security, in that loving and compassionate way that SharePoint does this completely differently from anyone else, is vital if you want to make your solutions safe.
Did I mention Web services, both the ASMX type and the WCF type? If so, I forgot all the external Web service standards and definitions you need to understand, and we are still just talking about core knowledge that you must have before you start understanding any business logic in the third-party services you want to utilize.
But wait, there’s more! There is a whole range of non-SharePoint technologies that you need to understand, such as Active Directory and a number of other authentication mechanisms if you plan to utilize external authentication Exchange if you want to use the more advanced features not provided by out-of-the-box Web parts SQL Server if you plan to utilize custom data sources for performance… and so on.
The previous couple of paragraphs only detailed the third tier of development, by the way. For the middle and first tier of development, similar complexities make the developer’s nightmares even scarier.
So yes, the skills required for a SharePoint developer are so wide-ranging that you’ll be spending the rest of your life trying to master them all. And you can bet there will be more skills required for SharePoint 2013.
Why are traditional development methods useless?
Unit testing and mocking is all the rage these days, and for a very good reason. When you are the master of the code, producing perfect code makes all the sense in the world. After all, any code error goes directly back to you, and if you develop your tests right, your code should have no errors.
However, to a SharePoint developer, building code that works is just a small part of the puzzle. As I mentioned earlier, we are not the only developers on a SharePoint solution. In fact, we should encourage our users to modify what we make in order to better utilize the adaptability that is SharePoint’s greatest feature.
This presents the traditional developer with a nightmare. If you are not in control over the environment into which you deploy code, how can you test whether your code works? You may set up a mock environment that matches the production environment 100%, and within five minutes, some user may completely alter the entire solution, changing the target you try to hit.
This is not the worst part, however. Even if your code runs perfectly at the time you deploy it, it also needs to endure the active modification of users throughout its entire lifespan. Your code may depend on a list having a certain set of columns, but users may change that at any time. They may even remove or replace the entire list, and how will your code run then?
The difficulty for a SharePoint developer is not just in writing code that runs perfectly once, but that runs perfectly, no matter what happens to the assumptions you’ve made for your code. There’s no way you can design tests that will properly validate your code against every possible change that users can make, and traditional testing becomes rather pointless.
There’s a balance between allowing users to make those changes and preventing those changes completely. It certainly is easier to make sure that users cannot make changes that will break your solution, but that also means that the solution is less flexible. People don’t buy SharePoint because they want a rigid system that works in a prescribed manner; they buy SharePoint because they can adapt it to their ever-changing needs.
Let’s say that you develop a solution for managing customer contacts, allowing users to enter and search for customers by name, customer number, ZIP code and state. You deploy it and everyone is happy, and of course, you’ve done your unit testing to ensure your search function works perfectly.
However, John, the manager down at sales, wants to add more data to your customers. He thinks it is good to store a customer’s birthdate and religion so that he may send the appropriate greetings at those times of the year. In fact, he is adamant that these additional columns are so important, he makes them mandatory for every new customer added.
In this case, John adds new columns to satisfy his needs, and your data model has suddenly changed. Not just that, but John also changed the validation rules by making the new columns mandatory.
Let’s make this even trickier. John realizes that 90% of the company’s business will come from international customers, and I hate to bring this to you, but most of the world has no idea what a U.S. state is. Thus, John decides that the state column should no longer be mandatory, or he may even remove it entirely.
When the developer’s code then tries to add a new client, it will fail on several levels. It will fail because it tries to add the state column for new customers, and it will fail because it has no concept of John’s new birthdate or religion columns. The failure isn’t because the code wasn’t properly tested prior to deployment, but because the deployment environment has changed drastically.
John, being a non-developer sales manager, has no concept of the underlying problems he may cause, and frankly, why should he? He is there to solve a business need, not a technical requirement.
We, as SharePoint developers, need to handle those challenges, and that brings out the million-dollar question: How do you write code that runs no matter what the environment looks like?
Those are the challenges we face every day.
But it gets worse.
Other developers and agility
Because SharePoint is such a complex beast, larger installations often require multiple teams of specialized developers. You may have one team working on customizing the user-profile services while others may need to handle building specialized project sites or a Web front end that utilizes those modified user profiles.
What you end up with is multiple interdependent teams that must ensure progress and proper documentation so that the other teams may depend on the output from each team. So far, this is something every developer faces.
When you then add the moving target idea I mentioned earlier, you end up with what can seem like complete chaos. You now have two or more teams trying to coordinate firing a gun at a target nobody knows the location of, without knowing what gun to fire, and, of course, without even looking. Even if they know what the target looks like (in other words, what they are trying to accomplish), it is still a massively complex task.
The solution to all this is thorough planning and design up front. If you know exactly what you want to build before you write your first line of code, you also know the exact output and can communicate that to other teams. Of course, this assumes that the other teams do the same. In short, plan everything ahead and you won’t be surprised, right?
Well, that was the way one developed solutions before agile principles taught us otherwise, also known as the waterfall era. Now, we are expected to deliver the first line of code before the ink on the contract is dry. It should be in production by the time the contract is put in the envelope, and by the time the contract is filed in your SharePoint document repository, your client should be on their way to request the next major project.
Don’t forget: From the time you release your first code to the time the customer tells you what changes they want, everything about your assumptions has changed again, because users have already started working with and relying on your solution.
So, at this point, because of the wonders of agile expectations (which are good, don’t get me wrong), we now don’t know what our target looks like.
And then they ask us if we can do this any faster…
Can you cut it?
Still think you’re cut out to be a SharePoint developer? If so, I applaud you and wish you the best of luck. I can also highly recommend booking a session with a psychologist, because you are quite possibly stark raving mad.
Still think you’re paying your developers too much? Please start from the beginning and read this again, because you’ve clearly not read what I just wrote. Or, in case you are actually paying your SharePoint developers what they deserve, please let me know if you have any openings.
Need-to-know technology #1: Client Object Model
With the SharePoint Foundation 2010 managed client object model, you can design client applications that access SharePoint content without installing code on the server that runs Microsoft SharePoint Foundation 2010. For example, you can build new categories of applications that include writing applications that are based on the Microsoft .NET Framework, rich interactive Web parts, Microsoft Silverlight applications, and ECMAScript (JavaScript, JScript) applications that run client-side in a SharePoint Web part. For example:
A team leader creates a SharePoint site that has many lists that are required to manage her team’s mission. She wants to change these lists in an ad hoc manner—perhaps updating assignments and estimates based on an Open XML spreadsheet, or moving items from one SharePoint list to another. She wants to write a small custom application to help her manage this.
A software company that sells a traditional rich client application wants to integrate SharePoint document libraries and lists into its application, and it wants this integration to be seamless or even invisible to its users.
A SharePoint developer wants to build a rich Web part for a SharePoint deployment that brings list content into his custom AJAX Web code. He also wants to build an even richer Silverlight application that does the same thing.
What do these people have in common? They can use the SharePoint Foundation 2010 managed client object model to achieve their goals. The SharePoint Foundation 2010 managed client object model lets you write client-side code to work with all the common objects in SharePoint sites. Through the object model, you can add and remove lists; add, update and delete list items; change documents in document libraries; create sites; manage permissions of items; and add and remove Web parts from a page.
Previously, there were few options. You could use Web services to interact with SharePoint lists and other features, but this was challenging. If the Web services did not provide the necessary capabilities, you could write server-side code to provide a new Web service (an even more difficult task). Some IT departments disallow server-side code, or allow only code that is written by the IT department, so that sometimes was not an option. The SharePoint Foundation 2010 managed client object model enables new kinds of applications and makes it easier to write client-side code that interacts with SharePoint content.
To use the SharePoint Foundation 2010 managed client object model (client object model), you write managed code based on the .NET Framework that uses an API that resembles the object model that is used on a server that is running SharePoint Foundation. The client object model has classes for accessing site collection information, site information, and list and list item information.
In the case of Web Parts, you use an ECMAScript (JavaScript, JScript) programming interface that resembles the .NET Framework API. For Silverlight, you can use a subset of the API that is available through the .NET Framework on the client. Although much of the information that is presented in this article is relevant to the ECMAScript and Silverlight APIs, this article focuses primarily about how to use the SharePoint Foundation 2010 managed client object model from a client application that is based on the .NET Framework.
Read more about the client object model.
Need-to-know technology #2: Business Connectivity Services
Microsoft Business Connectivity Services (BCS) (formerly named Business Data Catalog) provides read/write access to external data from line-of-business systems, Web services, databases, and other external systems within Microsoft SharePoint 2010 and Microsoft Office 2010 applications.
Both SharePoint 2010 and Office 2010 applications have product features that can use external data directly, both online and offline. Developers can gain access to a rich set of features and rapidly build solutions using familiar tools such as Microsoft Visual Studio 2010 and Microsoft SharePoint Designer 2010.
A core concept of BCS is the external content type. Used throughout the functionality and services offered by BCS, external content types are reusable metadata descriptions of connectivity information and data definitions, plus the behaviors you want to apply to a certain category of external data. External content types enable you to manage and reuse the metadata and behaviors of a business entity from a central location, and it enables users to interact with that external data and processes in a more meaningful way.
External content types provide SharePoint behaviors (such as lists, Web parts and profile pages), Office-type behaviors (such as Microsoft Outlook Contacts, Tasks, and Calendars; Microsoft Word documents; and Microsoft SharePoint Workspace 2010 lists), and capabilities (such as searching and working offline) to external data and services. As a result, users can work in their familiar work environments without needing to learn different (and often proprietary) user interfaces.
For example, consider a business entity such as Customer. You might want to interact with Customer items inside a SharePoint list or work on them offline in Microsoft Outlook. Or you might want to enable the user to pick a customer from a list of customers in an Orders contract document inside Microsoft Word. You can create an external content type once and then reuse it anywhere you need it.
BCS enhances Office and SharePoint application capabilities and their user interfaces, streamlining development with deep integration of external data and services. Experienced users, developers and business-unit IT professionals can integrate assets from external systems, and enable interaction with external data through many types of Office client and server applications. The BCS feature set enables rapid development and deployment of scalable and secure solutions.
Linkapalooza: Your SharePoint guide
It’s The Linker here. Perhaps you know me from BZ Media’s SharePoint Technology Report newsletter. I live for links to save you time spent hunting around for valuable information about SharePoint. What a guy, eh?
I gotta tell ya, it’s weird for me to appear in print; usually, I’m in the ether, moving in and out like the wind, offering up hyperlinks to all things SharePoint. This all seems so, well, concrete! I feel like I should go buy a suit and tie for my coming-out—after all the links over all the years, I’m finally getting my start on the big magazine stage! Mother Linker would be so proud!
Anyway, here are some links to get you started on the path to SharePoint development. I hope you enjoy them as much as I enjoy bringing them to you! If you copy and paste them into a browser, all you’ll get is a big mess of paste on your computer screen, and you’ll have to manually type in the URLs anyway. But here they are. Hope you’re sitting next to a computer while you’re reading this!
Setting up the development environment for SharePoint 2010…
Welcome to the Microsoft SharePoint 2010 SDK…
The SharePoint Developer Center…
SharePoint Designer Developer Center…
Random YouTube entry: Get it started
