SharePoint development is a bit of a tricky thing because its whole philosphy seems to blur the software development lifecycle. One of the big selling points of SharePoint (or at least the way Microsoft positions it) is how it supposedly shifts the burden off of IT's shoulders and onto business users. Witness how simple it is to fire up SharePoint Designer and make changes to design or workflow; create your own lists and sites; upload documents to libraries and manage your own content publishing. All of this makes information workers' eyes light up and gives IT staff the shakes.

The problem is, a lot of the changes that are made are hard for IT to replicate. If you get a call from an end user asking you to restore the special document library columns they created a month ago, what do you do? Not only are there a wide variety of software artifacts created during a SharePoint solution, but many of them are virtual and "live" in the SharePoint database itself!

If this were change-managed in the traditional IT sense, there would be development environments, source code repositories, installation packages, regression testing, quality assurance...which while reassuring and reproducable is also a bottleneck and frustrating for end users who love the new flexibility and control they get with SharePoint.

So what's the middle ground? The jury's still out on this...but we're starting to see some best practices. One key document came out just the other day by Patrick Tisseghem of U2U fame. It's a first-class document outlining development considerations around SharePoint. The links to the document's two parts are here:
http://msdn2.microsoft.com/en-us/library/bb530302.aspx
http://msdn2.microsoft.com/en-us/library/bb530301.aspx

There is also some documentation called "Under The Hood" which explains how Microsoft developed its Fantastic 40 templates and gives some great insight into what can be done with the platform. Read it here: http://blogs.msdn.com/sharepoint/archive/2007/06/23/under-the-hood-white-papers-for-fantastic-40-application-templates-and-splendid-7-my-site-templates-now-available.aspx. Key things the white papers touch on include the importance of applying the same principles of solution architecture, identifying and applying design patterns, and assessing the capabilities and limitations of technology that you would use on any software project.

Perhaps the most important thing is to try and treat SharePoint with the discipline and process required for any major Enterprise application. I'll try to delve into this topic in more detail in future blog postings, for my own benefit as I am often puzzled as to what the best approach is to manage the code and customizations that are developed during the course of a MOSS implementation.

As a final note, there is a Microsoft Developer Portal here: http://msdn.microsoft.com/office/server/moss and the SharePoint newsgroups contain lots of guidance about development issues.