Some of my Best Practices in SharePoint development

I've been a 'traditional' developer long before getting into SharePoint. Started on Unix platforms with C, C++ and Objective-C, next Java on both Solaris and Windows, and since 2000 mainly Microsoft (web)development. A common red line during my professional history is to apply Application Lifecycle Management principles. Ok, back then it was not phrased like that...; but still, we applied versioning control, nightly builds, peer reviews, static analysis.
The tooling support for ALM has substantially improved the last years; within Microsoft development most significant available via Team System / Team Foundation Server. Its different aspects - version control, static analysis, build support, work items, reporting, ... - can give a project and its stakeholders a better control and insight on how the project is [non]progressing.

My utmost best practice is to apply these same ALM principles and practices also within SharePoint development projects. This is not always commonplace, due to the different nature of SharePoint development compared to 'traditional' apps. SharePoint is namely amongst others a template platform, with a lot of functional and technical building blocks out-of-the-box available. You typically apply these for your own dedicated SharePoint portal or application via customatization. These are not directly source code artefacts which you edit and version control in a development environment, but can directly be performed in the SharePoint environment itself; and the customizations stored in the SharePoint content database.

That is all fine, excepts it presents you with a challenge when you need to deploy your SharePoint custom application to other environments.
I'm therefore a strong upholder to threat everything the project does for realizing a custom SharePoint application, as a first class source artefact. Store all your intermediate building items within your team productivity environment, and be able to repeatedly produce and provision your SharePoint application on whatever physical server or farm.

This results in my following list of some best practices:

1. Apply development and ALM principles - structure the application within architecture layers with the different responsibilities, provision the Visual Studio solution structure accordingly, implement and schedule an automatic build, identify, plan and divide the total work within workitems,
2. Strive for a first fully automatic deployable version as soon as possible. This is key to get your customers and users involved from the early stages on: give them something to see, feel, try-out, critize; but ultimately to reach a common agreement on what to build
3. Utilize the SharePoint platform's own inherent functionalities within the deployment process - Solution Framework, Features, SPWebConfigModification, ...
4. Honor the inherent out-of-the-box available SharePoint functionalities, above implementing your own custom variation. This richness is one of the strengths of SharePoint as an application development platform.
5. From start on [re]consider memory management and performance - for instance, include the usage of SPDisposeCheck within your development and QA processes
6. Distinguish between the two types of users of a Content Management site: content editors and the end users (readers)
7. Co-operate with your IT operations staff
8. Favor FieldControls above using the Content Editor WebPart

I can easily extend this list with more of my own experienced best practices, but then I'll be getting more into technical details and peculiarities. I'll leave that for another blog.