SharePoint Development for the Masses

As a consequence of having a fairly high profile in the SharePoint Development community, I get a lot of inquiries from .NET developers, Java programmers, and even some legacy non-OO types, requesting guidance on how to get started in SharePoint development. I wish the answer was as easy as "Go buy this book and you’ll become an expert over the weekend" but that’s just not the case. Learning SharePoint means learning an entirely new platform and a new way of writing code; most importantly, it means learning to think like the system you are writing the code for. This is no easy task; it takes time, endless rounds of trial and error, and a whole lot of patience.

So how does a [pick your language or platform] developer get started with this whole SharePoint thing? Here are a few guidelines to set you on the right path to becoming a SharePoint development guru:

1. Forget Everything You Know About .NET

   Well, OK, don’t forget *everything* but do take all those lazy shortcuts you’ve been relying on for years now and throw them in the rubbish bin. SharePoint development is not about wizards and IDE’s – it’s about raw code, XML (CAML), and a generous helping of elbow grease. If you’re a C++ or Java developer, this doesn’t apply to you – you’re already used to doing things the hard way. But for VB/C# and ASP.NET developers, transitioning to SharePoint is like catching a bucket of ice water with your face on a chilly winter morning. Let’s face it – Microsoft has done a really good job over the last decade making repetitive programming tasks virtually extinct. Control libraries, project templates, database connections, event wireups – all the things which get done for you in Visual Studio with a few clicks in a wizard are suddenly missing in SharePoint and that causes a lot of heartburn for newbies. Whether that’s good or bad is relative; I would argue that knowing how to do things by hand makes you a better programmer in the long run but many people don’t see it that way. Regardless, that’s how it is (at least for the time being), so get used to it.

   One of the ways to get really frustrated, really fast is to constantly harp on the comparisons between ASP.NET and SharePoint. Yes, SharePoint is built on ASP.NET, and yes, there are many similarities – but constantly fretting about how you used to do something in ASP.NET one way and SharePoint does it another way isn’t going to get you anywhere. SharePoint is just different – it’s bigger, more complex, and there are thousands of things going on behind the scenes that make it necessary to work the way that it does. Knowing ASP.NET is going to help you work in a SharePoint world but it can also be your Achilles heel if you can’t let go of the way you used to do things. Your best bet is to roll up your sleeves, crack your knuckles and prepare to get your hands dirty.

   Here’s a prediction you can take to the bank – within the first month of developing on SharePoint you will curse, you will scream, you will pound your head against the wall, you will probably figure out exactly how much force is required to shatter a wireless mouse against a cubicle partition. But you WILL learn. You’ll learn how SharePoint behaves, how your code interacts with the umpteen gazillion things SharePoint is doing that you can’t see, how the architecture affects code performance, how important security and impersonation are, more about the ASP.NET page lifecycle than you ever wanted to know, how fiendishly complex but brilliantly effective CAML is, and a host of other valuable lessons. And the more you code, the more you will learn, and the more your skills will increase. And somewhere along the line you’ll have an epiphany – you really CAN be more efficient and effective writing code for SharePoint than you could building ASP.NET applications from scratch due to all the wonderful things that SharePoint does for you that you don’t have to do yourself. Is it always easy, does it always make sense, and is that the way you would design it to work? No, no, and no – but that’s true of any enterprise system and something that we always have to deal with as developers, so why should SharePoint be any different?

2. WWSD – What Would SharePoint Do?

   The real secret of programming in SharePoint is not the actual code itself (it’s still VB and C# under the covers); it’s the knowledge of what SharePoint is doing with your code that counts. Remember, the system has to do a million other things before it worries about accommodating your new web part that’s going to end world hunger and save the planet. On-demand site provisioning, dynamic list creation, server farm management, feature deployment, security, malicious code protection, the list goes on and on of stuff that SharePoint is doing that you’re not consciously aware of. So the first step to becoming a real SharePoint ninja is learning the lay of the land – Sun Tzu said "Know your enemy and know yourself and you can fight a hundred battles without disaster". Never was this more true than with SharePoint development. Once you understand how CAML works and what SharePoint does with an ONET.XML file when a site is created, for example, can give you some major "Ah ha!" moments when developing custom site definitions. Similarly, once you grasp the relationship between the config database, the content database, site collection hierarchies and list data, you will suddenly have a whole new understanding of how to write efficient web parts to perform cross-site queries.

   I believe that a good SharePoint developer cannot function effectively without knowing how the system is installed, configured and maintained. So the first step for any aspiring programmer is to install the software yourself on a virtual machine image and start learning what it’s all about (WSS is free, after all). Set up a few sites, play with security, do some search customization, and create a whole bunch of different list types and views. By all means, break it ’til you make it – worse case, you ditch the image and start over. Most importantly, learn how the whole Feature Framework functions as that will be the primary method of deploying custom code (in conjunction with Solution Packages, which are mostly comprised of bundled Features). Drop to the file system and check out that 12\TEMPLATE\FEATURES folder; it won’t take long to repeatable patterns and constructs (and some even have descriptive folder names in plain English that makes it easy to figure out what they do – how innovative!). Once you make the mental leap from understand what a web part is (a specific type of server control) to how it is deployed (hey – features and solutions are nothing but XML-driven MSI’s for SharePoint!) you’re home free – the rest is just a matter of figuring out how to get the object model to sing and dance to the tune of your choice. But if you try and take a shortcut (i.e. start writing code before you figure out how SharePoint works under the hood) you’ll be left stranded in the middle of nowhere; first learn to crawl, then to walk, then you can run like the wind (or Forrest Gump with leg braces – no doubt your first few attempts will stumble along rather ungracefully).

3. Get Back to Basics

   I know, I know – you have a great idea for a really cool web part that does the Macarena with your CRM data while dancing a scorching Tango with a Google mashup and you can’t wait to dive into the Object Model and start ripping out the coolest code the world has ever seen. Stop right there. Put your mouse down and let’s have a reality check. You will not instantly lose all your street cred and be sent to the back of the bus with the "special" kids if your first web part does nothing more than shout "Hello, World!" in 10pt, Arial, Bold, #C0C0C0.

   Let’s eat that Elephant one bite at a time, shall we? The most common mistake I see new SharePoint developers make is that they try to do too much, too soon, without really understanding what they’re doing or how to troubleshoot when things go wrong. Slow down and take it one step at a time. Try this: 1) get your "Hello, World!" web part to work using manual deployment methods; 2) attach the debugger and step through the code in a live instance; 3) package the web part as a feature in a solution package and do an automated deployment; 4) attach a FeatureReceiver and change the web part properties upon activation; 5) put the output string in a list and do a dynamic lookup to the list data to read and write the text value of a column; 6) get the list data from a web service method instead of an Object Model call. Now you’re getting somewhere. Don’t get frustrated that you haven’t actually done anything yet; those simple tasks – in that order – will pay more dividends in the long run than you can possibly imagine.

   The truth is, SharePoint is H-U-G-E and the only way to truly figure it all out is to take it slowly, one step at a time, until you get comfortable with one knowledge area and are ready to move on to the next. You won’t master web parts on Monday, Event Receivers on Tuesday, Workflows on Wednesday and be ready to tackle the BDC on Thursday. Have patience and, most importantly, try to understand exactly what is going on each step of the way. It may be more art than science but most of what you learn in one area is applicable to another and the code is almost always repeatable – do it right once and you’ll be ahead of the game the next time around. I’ve written hundreds of web parts, event receivers, workflows, application pages and who knows what else over the last few years but I always find myself doing the same things I did when I first figured these things out (with minor improvements along the way, of course). Make a concentrated effort to fully master each discipline before moving on and you’ll be a bona fide superstar in no time flat; jump around like a schizophrenic code monkey and you’ll be chasing your tail for eternity.

4. Research. Revise. Retain. Repeat.

   Unfortunately, SharePoint is just too big for all of the information you need to be reflected in the SDK. You’ll need to do some independent research to find real-world examples from people who have done, or are attempting to do, something similar to what you want to achieve. The blogosphere is your best bet, followed closely by the various SharePoint forums. There are also a large number of books that can provide valuable insight to get you going down the right path. Once you find some sample code or get some sage advice from a well-meaning contributor, adapt it to your specific scenario. Keep trying various methods until you get a positive result. Learn from the process, file the information on what works and what doesn’t away for future reference (even better, blog about it and help contribute to the community), then repeat the process for each new attempt. Believe it or not, there are very few situations you can encounter that someone hasn’t already tried – sometimes successfully, sometimes unsuccessfully – it’s just a matter of finding the right resource. If all else fails, a giant "Please Help!" post in the forums will usually get a few responses from MVP’s who, if we don’t always have the answer, often know whom to ask on your behalf.

    

Resources

So by now you’re probably saying "Thanks for the lecture but how do I really get started?". Ok, fair enough. Here are some links to get you going:

General Development:

Paul Andrew’s List of SharePoint Developer Links
Microsoft Learning Developer Resources

Web Parts:

A Developer’s Introduction to Web Parts
Getting Started with SharePoint 2007 Web Parts
Custom Web Part Basics

Workflow:

Create a SharePoint Workflow Project
Building a SharePoint 2007 Workflow with InfoPath 2007 Forms

Site Definitions:

Heather Solomon’s Design and Branding Roundup
Andrew Connell’s WCM Resource Directory
Creating a Custom WSS Site Definition

Miscellaneous:

Eli Robillard’s Monster List of SharePoint Resources
Lynn Langit’s SharePoint Developer Resources

And, hey – remember to have fun, will ya?