A Few Quick Thoughts on SharePoint Development

My colleagues (Rus and Ana [no blog, yet]) and I have been working hard at trying to be productive in the MOSS/InfoPath/Workflow space these days.  It’s a very powerful envrionment with some great capabilities, but it’s also a very difficult environment to work in.

Test Driven Development?  Forget about it.  Clear logs with easily understandable error messages?  MOSS scoffs at thee.  Looking to avoid lots of tedious, error-prone hand coding of text fields which get no checking during compilation?  I think not.

We’re having to focus on breaking every task down to tiny pieces, lock those down, and move on to the next bit.  I lost a scad of hours trying to chase down why my task InfoPath forms weren’t reading in workflow data — it turns out I’d had a simple casing error in the ItemMetadata.xml file used to define the structure for the secondary data connection to the IP form.  No errors anywhere to be found, and no indication in IP or even traffic across the wire.  (Yay for Fiddler!)

Despite all this frustration, we’re getting some good work done and we’re starting to get a good handle on the right way to approach things.  Some seemingly simple fundamentals really pay off:

• Naming matters.  Use clear names for your activities, tokens, properties, and fields.  “Task1Token” isn’t anywhere near as sensible as “ContractSubmissionTaskToken,” nor is “OnTask2Changed” as clear as “OnAdditionalReviewerChanged.”
• Keep solid software practices in mind, despite what you might see in example code.  The samples in the SDK seem to like using public fields to expose data.  Huh?  Forget that, Vern.  Go read Wagner, McConnell, or just about any good book on development.
• Source control is your friend.  Nail down one bit of functionality.  Check in your changes.  Move to the next bit.
• Tools are your friend.  XMLDiff, WinMerge, Fiddler, Cygwin, and a few other pals have made their worth well-known to me in the last month.  Logparser is something I’m quickly heading off to check in the hopes it can help me tame the copious logfiles MOSS produces.
• Lock down a process and automate it.  Developing on MOSS is an exercise in numbing repetition.  Build a solution.  Copy files to a folder.  Run stsadm to install a feature.  Activate the feature.  Restart IIS.  Remove old workflow from library.  Associate new workflow.  You really want to do all that by hand eight billion times?  I think not.  Make use of the power of batch files, NAnt, and PowerShell scripts — or likely some combination of all of those.  We’re only at the start of this part, but we’ve got some good ideas on how to press on.

There’s been plenty of pain on this journey so far, but I think we’re seeing the light at the end of the tunnel now.  Hopefully it’s not a train.

Oh, yeah.  The most important thing that’s paid off for me: The folks who are working with me are a lot sharper than I am.  That’s always a great help!