Michael Yeager's MSDN Blog

Talking about EUCCs

I have been getting emails from lots of you wanting the goods -- the real life examples of End User Composed Composites (EUCCs), and more information on the how and why of designing them...

Unfortunately I haven't been blogging about EUCCs for a while - instead I have been doing presentations. Those of you who are Microsoft FTEs can view the "Designing Capabilities Not Applications" session in the TechReady9 On Demand archives. The "Designing Capabilities Not Applications" session is in the Architecture Track:  ARC304. Description as follows:

     Many MOSS, OBA and other Composite applications are moving the application design decisions away from the Architects and Developers and putting them into the hands of the end users. This is a paradigm shift that changes the game and radically shrinks the development cycle. To be successful at end user driven designs, Architects and Developers need to think in terms of designing and delivering Capabilities rather than purpose built applications. End users then use workflow and rules to structure their own high value business solutions out of these Capabilities. This presentation will use MOSS and OBA examples from the field to explore the emerging patterns and practices that Architects and Developers can use to factor requirements into capabilities rather than purpose built applications.

For those of you who are not Microsoft FTEs, I am doing a presentation at the SharePoint 2009 conference in Las Vegas Oct. 19 - 22, the web site is: http://www.mssharepointconference.com . The session is SPC268 "Designing Capabilities Not Applications, with SharePoint 2010 Composites". The full description of that presentation is:

     Learn about the power of end user composed solutions and how to plan, design and think in terms of capabilities to design them. We will discuss a conceptual pattern for differentiating and     evaluating different SharePoint/Office System solutions and for understanding the advantages of Capability-driven solutions along with the institutional road blocks to these solutions.

A recorded version of that session will also be available to all conference attendees a few weeks after the SharePoint 2009 Conference.

What the heck am I talking about?

Hey, I'm talking about EUCCAs and Versatilities.

My last couple of blog posts are my personal crusade to get SharePoint architects and developers to focus on the most productive way (in my opinion) to use SharePoint as an application platform.

A EUCCA is a specific type of Composite Application - an End User Composable Composite Application.

A EUCCA is a Composite Application that specifically hands over the design of the Presentation and Productivity layers to the end users. Any composite application where the developers end up controlling the Presentation and Productivity layers is not a EUCCA.

Versatilities are the parts of a EUCCA that the end users compose. So each EUCCA contains a set of Versatilities.

A Versatility, regardless of it's functional requirements, must satisfy three critical non-functional requirements:

• Movability
• Assemblability
• Composability

Any component, reusable or not, if it is not Movable, Assemblable and Composable, then it is not a Versatility.

That's what I'm talking about. 

Talleyho :)

Requirements and Versatilities

Reusable components. A lot of work and effort and thought has been put into reusable components...

OK, so let's talk about a specific type of reusable components... let's talk furniture design and Versatilities.

There is a certain Scandinavian furniture company, not sure if I am allowed to say their name, but they are incredibly successful at selling really nice, practical, well designed inexpensive stuff.. But their designs are significantly different from traditional furniture designs because their business model requires them to meet some very stringent non-functional requirements.

First off, a piece of their furniture has to fit in a box that weighs as little as possible, and be transportable home by the customer themselves. So Movability is a huge non-functional requirement. Second their designs have to be easily assembled with only simple graphic instructions, and a few included tools. So Assemblability is another very important non-functional requirement. Third, their designs are designed to look and work great together across completely different types of furniture and housewares and accoutrements. All of their stuff has to be nicely composable into different attractive interior designs and styles. So Composability is also a hugely important non-functional requirement.

• Movability
• Assemblability
• Composability 

These are the uber-requirements. These are requirements that have to be satisfied no matter what the end user's requirements. If what the end user's want can't be designed to be Movable, Assemblable, and Composable - forget it. This company isn't going to deliver it. The end user (customer) will have to go elsewhere.

SharePoint Versatilities are versatile components that have these same three non-functional uber-requirements: Movability, Assemblability, and Composability. Therefore you have to design from the get-go for Movability, Assemblability and Composability - otherwise you're not designing Versatilities.

OK, so you have a bunch of business users, and they want an application that does x, y and z. So what are you going to do? If you design them an application that does x, y and z, and exactly x, y and z, then you have a purpose built application. If you get the requirements for a reclining chair, and you then build a one-off reclining chair right in their own living room, as one solid monolithic reclining chair - then what you have is perhaps a great reclining chair, but it only works now, for that particular user with their current decor. If they want to "recompose"  their living room into a different design, then they'll have to bring the furniture craftsmen back in and rebuild. Sound familiar?

If you want Versatility - if you want applications that the end user's can move around, assemble and reassemble, and compose and recompose, then you have to take their requirements, and do a whole different level of analysis on them. You have to look beyond the x, y and z, and treat x, y and z as a sub-set of a larger set of possibilities - and you have to explore how Versatilities can be designed to deliver that mix. In other words, like our Scandinavian design heros, you have to be really smart about the design.

So now let's say you've been super smart - and you've come up with a slick set of Versatilities that can do x, y and z and so much more - well now you have a more difficult problem. Now you have to convince your stakeholders that your set of Versatilities is a superior solution to their x, y and z requirements. SharePoint users in general have totally realized the value of Versatilities. They love lists and columns and views and content types and web parts, and everyday they realize tremendous value out of moving them around, reassembling and recomposing them into new solutions. But first off, most SharePoint users didn't arrive at their SharePoint site with a clear set of requirements. They arrived at their SharePoint site thinking - here's a whole set of tools, what can I do with them? And second off, what if your stakeholders aren't SharePoint users at all? Quite often you're dealing with CXOs that only have a vague conceptual understanding of what is going on in SharePoint - and they're used to the waterfall lifecycle - they expect you to gather requirements, and then deliver an application that exactly satisfies those requirements.

How do you convince your fickle and persnickity bunch of stakeholders that they should care about Movability and Assemblability and Composability - how do you convince them that their interests are best served by your set of brilliant Versatilities?

Convincing stakeholders to care about non-functional requirements is always hard. You have to plan, you have to prepare, you have to lay the ground, you have to do great drawings and presentations, you have to work at hitting the right notes from the very first conversation. You have to get them to understand that Versatilities will give them the agility and speed to continuously execute on their business objectives. 

But you can't sugar coat the downside because it will bite you back. Applications composed using a set of Versatilities always require a little more work on the end-user's part - they require more clicks than a purpose built application. Just like the Scandinavian furniture, they have to be assembled, and they come with directions that the end-user's have to follow... So yes, their users will have to do more work and learn a few things, but in return they will be able to compose the application in their own SharePoint site in a matter of hours - and then be able to change it themselves whenever it requires changing.

Of course you have to show examples. Most stakeholders don't know what they want until they see it. So show them as many similar end user composed SharePoint applications as you can - and if you have a running version, show the stakeholders how the end user's themselves can change and evolve the application as their business changes and evolves - without the need to call in the developers for another 6 months of rebuilding in order to add an account code, or to deliver the same application to a new office in Timbuktu.

I'll walk through some real examples next time...

Design and Develop Versatilities not Applications

If you have had the pleasure of working in the SharePoint Universe for a while, then hopefully you have had a chance to see lots and lots of examples of the incredible applications that end-users assemble in SharePoint all by themselves - without the help of developers or infrastructure or even business analysts. In my 5 years of Architecting and Developing SharePoint Portals and apps, I have had tours of some truly fantastic applications that individual business units - with enthusiastic business leadership - have assembled from SharePoint and Office System parts completely without the help of IT - and sometimes with the opposition of IT.

The first one that blew my mind was way back in 2004 at one of the major research hospitals in Boston where only a few weeks after I installed SPS03 for them - the nurse certification and training team had completely automated their business process within their SharePoint team site: class scheduling and calendaring, class syllabi, class sign-up, class workstation assignments, teacher registration, teacher bios, post class surveys, student grading and feedback, future class discussion lists, etc. etc. All completely created by the manager of this business unit and his team without any prior experience with SharePoint.

Since then I have been given tours of many many other fabulous - completely user assembled WSS/MOSS applications. Only last week I was shown around an Insurance Underwriting and Risk Assessment site that just rocked my world. The actuaries, engineers and underwriters had again completely automated their business process with lists and libraries and discussions of all kinds of oil drilling equipment, oil refineries, oil tankers, geographical variations, engineering experts by region, with ratings and location info, and analytical spread sheets tying all the data together. I can't go into any detail, but again the site was deep and rich and completely put together by the end-users - and it is in constant use for writing multi-million dollar insurance policies.

The fact is - end users know what they need, and with the right set of end-user tools that have the right set of capabilities - they can assemble, evolve and manage exactly the application that can keep their business riding the leading edge of the productivity curve. These kinds of applications blow the doors off of Agile or any other kind of "purpose built" development because they take developers and IT completely out of the presentation and productivity layers. No matter how fast or Agile a development effort is, it can never come close to keeping up with end-users directly satisfying their own needs through a Productivity Framework like SharePoint and the Office System.

So these fantastic and fabulously productive user assembled SharePoint applications - what should we call them? Well for starters, these are Composite Applications. And there are lots and lots of discussions out there in the software architecture world covering the great and wondrous future of Composite Applications. In the Microsoft/Office world the discussion revolves around Office Business Applications (OBAs) in which SharePoint plays a key part -  but what I are talking about here is a specific species of Composite Application and/or OBA which I refer to as the End-User Composed Composite Application or EUCCA. And in my opinion, EUCCAs are the big time game changer!

OK, so we have all these highly productive EUCCAs being composed and evolved by business users on the SharePoint platform, so what's the beef?

The beef is that 96.4% (informal poll) of all applications developed to run in the context of SharePoint are not EUCCAs. They are Purpose Built applications that take advantage of lots and lots of parts of SharePoint: authentication, authorization, role based security, security trimmed navigation, search, etc. ; but they don't take advantage of the tremendous productivity potential of the End-User Compose-able application. They take a long time to deliver, and they can't be changed and adapted by the end users as the end-users requirements change.

And the reason that software architects and developers don't build more EUCCAs on SharePoint - in my opinion - is that we have the wrong mind set - the whole software development lifecycle has been drilled into us for years - we collect the business requirements, and then we design and develop a solution to deliver exactly those requirements. But the job of designing and building EUCCAs requires a significantly different mindset, because with a EUCCA you don't deliver a solution that exactly delivers on the requirements, instead you deliver these things - configurable parts and pieces - that the users can use to compose and evolve their own solution as their requirements shift and change.

The difference is like the difference between designing a train and designing a car. A train is totally controlled by the tracks. The users of a train are passive and the train's schedule with it's unchangeable set of stops dictate their possibilities. The course of the train does not change even if the plans of the individual user's change. This is a purpose built application.

The control of an automobile, on the other hand, is completely under the control of the end users themselves. They can go where they want when they want, they can loop back, they can change course mid-way. Their path evolves as their requirements change. In this way, building the presentation and productivity layers of a EUCCA requires a mindset like that of an automobile designer - it's all about handing the control  of the Presentation and Productivity layers over to the end-users.

So what are these parts and pieces that end-users use when they are composing a solution? SharePoint has been called a "Capabilities Framework" - so are these things simply "Capabilities"? Yes, but you can deliver capabilities that aren't user compose-able. What we're talking about here are specifically user compose-able capabilities. Each one has it's own brake, accelerator, steering wheel and signals. Which brings me around to the title of this post. I am suggesting we adopt a noun form of the word Versatile - and we call these things Versatilities.

SharePoint Software Architects and developers need to focus on designing and developing Versatilities - small pieces of end-user configurable functionality that are versatile in exactly same way that the OOTB SharePoint functionality (lists, content types, views…) is versatile. We need to think totally in terms of extending the SharePoint Presentation and Productivity layers rather than simply building another Purpose Built application that sits on top of SharePoint.

Think "Versatilities". It will get you in the right mind set to build some fantastically productive EUCCAs!

An example to come.

SharePoint Content vs. Code - A Parable

The difference between Content and Code, and between Publishing and Code Deployment, can be a very difficult thing for the Stakeholders in an Enterprise SharePoint implementation to grasp. So for what it is worth, I recently told a client the following parable, and the light went on... Perhaps the story is worth retelling.

Imagine a beautiful lush green meadow called SharePoint. And this meadow is filled with all these happy productive business people having a great time playing with this beautiful fragile stuff called “Content”.

And off to one side of this meadow is a deep abyss. And at the bottom of this abyss, if it has a bottom, there are these mean smudgy IT people who spend all their time mining this radioactive stuff called “Code”. And after these smudgy IT people dig up this ugly dangerous Code stuff, they pound it with big hammers, and they burn it in blast furnaces, and then they pack it into these huge heavy metal boxes, which they finally have to carry on their backs all the way up the side of the Abyss -- through the land of Dev, through the land of Test, and through the land of UAT, and finally to the beautiful SharePoint meadow.

Now if you are one of these happy fun loving business people, the last thing you want is for some of your beautiful Content to fall off the side of the SharePoint meadow and into the IT abyss – cuz those stubborn smudgy IT people will treat it just like that Code stuff, pounding it with hammers, blasting it in blast furnaces, and it may take weeks or months, sometimes even years for an IT person to scale the abyss all the way back up to the meadow with a metal box full of now unrecognizable Content…

In SharePoint terms, a rule of thumb is that Content is something, that when deployed, goes completely into a Content database. If on the other hand, when you deploy some stuff, if some part of it, even a tiny smidgen, ends up somewhere other than a Content database (such as the GAC or file system on a web server) – then that is nasty radioactive Code.

When you upload a word doc, or an Excel spreadsheet, or a codeless InfoPath form, or you save a SharePoint Designer workflow, or you create a new content type, or a new list or library or team site -- all of these things end up completely in a content database and are in fact Content.

But sometimes those nice happy business people do want to put their Content stuff through a publishing process so it can be considered and approved by other happy business people. No need to bother those smudgy IT people though, they will only slow things down and/or mess them up…

Using STSADM to set Form Services Properties

Use the SetFormsServiceProperty operation as follows:

stsadm -o setformsserviceproperty

 -pn <option name>

 -pv <option value>

Option Names:

DefaultDataConnectionTimeout

MaxDataConnectionTimeout

MaxDataConnectionResponseSize

RequireSslForDataConnections

AllowEmbeddedSqlForDataConnections

AllowUdcAuthenticationForDataConnections

AllowUserFormCrossDomainDataConnections

AllowUserFormBrowserEnabling

AllowUserFormBrowserRendering

AllowViewState

ViewStateThreshold

ShowProgressRolesManager

AllowBranding

Example - to turn off the "Powered by Forms Services" logo on your form services forms:

stsadm -o setformsserviceproperty -pn AllowBranding -pv false

Note: You can use stsadm -o getformsserviceproperty -pn to see what the default values are for that particular property

For a full list of the stsadm commands go to: http://webservicecatalog.com/post/STSAdm-Command-line-Guide.aspx 

eXtreme End-User Driven Architectures (XEUDAs)

There is an emergent solution architecture which the most ingenious of our end users are piecing together without our help. It is an architecture without a name - so let's give it one:

the eXtreme End-User Driven Architecture or XEUDA (zoo-da)

A XEUDA is an Architecture - not an Application. It is an architecture of many applications that end-users compose to empower complex business processes. End users do this by themselves - no developer/IT intervention required. 

 XEUDA is an architecture that can be changed, rearranged, reconfigured, repurposed, redesigned, re-architected by the end users. Right now end users can only do this to a very limited degree, only with a small sub-set of applications, and only to drive particular activities of some business processes, but if the application architect and developer community, along with the IT governance powers that be, were to relax their grip and embrace this impulse, XEUDAs will push IT controlled architectures aside by producing productivity gains of 10X or more.

Anywhere there is an Enterprise MOSS infrastructure with even a handful of power users you will sense the yearning for XEUDA. MOSS power users and champions build fabulously flexible applications on their MOSS sites. MOSS is a wonderful end-user driven system. But it is not extreme enough - inevitably users drive up to the edge where pieces can no longer connect, where their InfoPath or Word or Excel docs, their content types and custom lists, and their SharePoint enabled LOB applications, are left hanging on a library ledge - their structured and unstructured data in danger of being backed-up into oblivion.

And when the developers and architects are brought in, and the problem is laid out and the requirements gathered, their next impulse, more often than not, is to move to a purpose built application - ripping control out of the hands of the users, and placing it in the hands of a Solution Lifecycle and project managers and development teams and a change management process which may take months or even years to hard boil what the end-users had loosely assembled in a matter of days...

We have all the tools and skills to give those magnificent MOSS and OBA applications the ability to turn into more powerful and more flexible XEUDAs -- what we don't see enough of are architects and developers that are advocating and building the end-user architectable elements that a XEUDA requires; and agile, apolitical, IT governance teams that are ready and willing to hand-off the architectural keys to their power users and domain experts...

Reference list for SharePoint internal field names

Much used reprinting of list of fields with internal names for easy reference:

Document Library fields

 Custom list fields 

Adding an InfoPath Preloader (ProgressBar) for long loading forms

Working on a project with some very large InfoPath forms (700+ fields with hundreds of rules and conditions etc.) running out of a SharePoint Forms library using the InfoPath client (not Forms Server) and which take over a minute to load.

In addition to a number of changes made to reduce the load time discussed elsewhere, it was decided to improve the user experience by adding a Pre-Loader to give the user some feedback while the form is loading.

Here is how this was done in C# (feedback appreciated - particularly if you know of a better way to do this):

     0. Add a reference to System.Drawing and then add the following using statements at the top of the FormCode.cs file (there may be others):

            using System.Drawing;

            using System.Diagnostics;

            using System.Threading;

1.  Add the following using statement at the top of the FormCode.Designer.cs (click on "Show All Files" if you don't see this file under the FormCode.cs file)

              using System.Windows.Forms

          Declare the preLoaderForm at the top of  FormCode.Designer.cs* under the "internal Microsoft.Office.InfoPath.Application    Application;" and "internal Microsoft.Office.InfoPath.EventManager EventManager;" declarations:

           internal Form preloaderForm = null;

2. Add inside the FormCode constructor in the FormCode.Designer.cs*

LaunchPreLoader();

3. Add two new methods to FormCode.cs

        private void LaunchPreLoader()

        {

            try

            {

                System.Threading.Thread newThread = new System.Threading.Thread(new System.Threading.ThreadStart(this.Preloader));

                newThread.Start();

            }

            catch

            {

                // do nothing

            }

        }

        private void Preloader()

        {

            try

            {

                preloaderForm = new Form();

                preloaderForm.Text = "Form Loading";

                preloaderForm.Size = new System.Drawing.Size(250, 75);

                preloaderForm.Location = new System.Drawing.Point(400, 200);

                preloaderForm.StartPosition = FormStartPosition.CenterScreen;

                Label message = new Label();

                message.Text = "Your form is loading";

                message.Location = new System.Drawing.Point(20, 8);

                message.Size = new System.Drawing.Size(200, 15);

                Panel progBarPanel = new Panel();

                progBarPanel.Width = 250;

                progBarPanel.Height = 50;

                progBarPanel.BackColor = Color.Gainsboro;

                ProgressBar progBar = new ProgressBar();

                progBar.Location = new System.Drawing.Point(20, 20);

                progBar.Style = ProgressBarStyle.Marquee;

                progBar.MarqueeAnimationSpeed = 250;

                progBar.BackColor = Color.DodgerBlue;

                progBar.Size = new System.Drawing.Size(200, 15);

                progBarPanel.Controls.Add(message);

                progBarPanel.Controls.Add(progBar);

                preloaderForm.Controls.Add(progBarPanel);

                preloaderForm.ShowDialog();

            }

            catch

            {

                // do nothing if preloader fails

            }

        }

4. To close the pre-loader, add the following code to the bottom of the FormEvents_Loading method in FormCode.cs. If you don't see a FormEvents_Loading method in your FormCode.cs file, then in InfoPath go to Tools > Programming > Loading Event - and it will be generated for you.

If( preloaderForm != null )

            {

                        preloaderForm.DialogResult = DialogResult.Yes;

}

*Note that steps 1 and 2 are in the FormCode.Designer.cs file. It is not advisable to make changes to this file since it is autogenerated and your changes can be easily lost. But on the onther hand, the Pre-Loader is only useful if it opens early enough, and the FormCode constructor is the earliest point we can get to in the FormCode class. If you cannot deal with the maintenance issue when this code is autogenerated (re-adding the three lines of code in steps 1 and 2) then you can try locating this code in FormCode.cs and see if it runs early enough to be useful to you.

Clearing the InfoPath Cache

When you load an InfoPath form, it is cached in the following location on your machine:

          C:\Documents and Settings\[User]\Local Settings\Application Data\Microsoft\InfoPath\FormCache2

When a new version of the form is detected, such as when a new version of the form is installed in a SharePoint Forms library, the cached form will be deleted and the new one installed in it's place.

You can also manually clear the Infopath cache by deleting the files.

Or you can do it via command line by:

            Start > run > Infopath /cache clearall

Process Currently Required for MOSS Variations

Variations is a potentially great MOSS feature. Variations are obviously useful for multi-lingual sites, but also anytime a company wants to replicate  a number of customer or partner sites, variations can automate the production and customization of those sites.

But MOSS Variations does not fully function (unless the issue has been fixed in recent hotfix that I missed) with custom content types unless those content types are in the site definition of the publishing sites themselves.

In other words, creating custom content types and deploying them as features is not enough. You currently need to create custom site definitions incorporating the custom content types – otherwise the pages are not replicated correctly using variations.

Unless you are going to use the OOB publishing site definition with the OOB publishing page layouts, then your process of creating a WCM (Web Content Management) site using Variations has to be frontloaded with nailing down the Content Types and generating Site Definitions:

·         first develop the master pages, content types, layout pages, get a fully working site that does what the customer needs

·         then create/generate site definitions that include those content types and layout pages etc.

·         then setup the authoring site using the custom site definitions - enabling Variations and adding the required Labels

If you are in a situation where the everything needs to happen at once - where the authoring team needs to enter content as the development team is developing the WCM site, then you may have to work around this issue:

See http://blogs.msdn.com/michael_yeager/archive/2008/05/08/variations-without-custom-site-definitions.aspx

Balancing your MOSS Content Types

I have found that the following two issues can be critically important when architecting a catalog style WCM site:

1.       The intention to use the Content Query Web Part (CQWP) to roll up lower level detail pages to higher level summary pages can have a major effect on your “Content Type Architecture” The CQWP has the ability to query across multiple sites by  Content Type. In a “catalog” style site where one is drilling down to detail pages, the ability to roll up across many different Pages libraries by Content Type can be a crucial functional detail

2.       Another important detail is the fact that a content type can have many layout pages. Often the authoring team wants to be able to switch between layout pages for the same content. You can do that by simply making sure the layout pages share the same content type, and that the fields that each layout page shares line up properly.

The first issue encourages the site architect to create more content types to make it easier to roll-up the content. The second issue encourages the site architect to create fewer content types each having multiple layout pages so that the authoring team can easily switch between layouts.

Variations without Custom Site Definitions

If you are going to create custom content types and custom layout pages, then for Variations (multilingual sites in MOSS07) to work, you currently are required to create custom site definitions with your custom content types built in.

The reason for this is that when Variations creates a new site or sub-site, it uses the Site Definition that was used for the original root site. So if you created the original root site using the Publishing Site Definition with it's standard welcome page, your new variation will be created with that Site Definition. But then there are two problems. The Pages library is not enabled for any of your custom content types. And probably you created a new welcome page with a custom layout page built on a custom content type, and the one created by Variations will be the OOB welcome page. Thus errors are thrown, pages show up blank, no content appears to be propagated.

Again, the preferred process with a new Publishing/Variations site is to build out an initial version of the new site. Define all the content types in the UI, create layout pages in SharePoint Designer based on those content types. Then have your users use it, provide feedback, and do as many iterations until everything is just right, and then turn around and build the custom site definitions with your now perfectly designed content types.

But a recent client of mine could not possibly do this. Because the site had to be up on such and such a date, there wasn't time to build custom site definitions much less have the custom content types completely defined in advance.

We built the site, it went live on time, and then after the fact I tried to figure out if I could get Variations to still work.

And what I found is that:

1. When you create a new Label, set Hierarchy Creation to create the "Publishing Sites Only" - no pages
2. After the sites have been created, rename the old welcome page (to default2.aspx for instance)
3. Then make a change on the home page of the site so that a new version will propagate (this appears to both add the custom content type to the Pages library, and add the custom page)
4. After propagation, go and delete the old welcome page out of the library (may need to repoint the Welcome Page to your new page first)
5. Now all other pages within that site will propagate correctly
6. repeat for each site in the site site collection

Only just at the beginning of testing this work around, but so far everything appears to work fine.

Unfortunately one has to do this every time a new site is added, but then -- hopefully there will be a fix for this whole issue coming before too long...

Content Deployment Debugging Links

There is more info on Content Deployment issues in earlier blog entries here.

The main thing is to first install SP1 and KBs 941422, 948945 and 950279, and 952698 and 952704  (these last two may rollup all the changes in the earlier KBs, I am trying to confirm that).

Beyond that, the best information on debugging Content Deployment jobs can be found on Maxime Bombardier's blog:

 http://blogs.msdn.com/maximeb/archive/2008/02/19/debugging-content-deployment-issues.aspx

(setting versioning to only Major Versions in the Style Library helped me out big time)

 and in parts 5 and 6 of Stefan Goßner's series on content deployment: 

 http://blogs.technet.com/stefan_gossner/archive/2007/10/12/deep-dive-into-the-sharepoint-content-deployment-and-migration-api-part-5.aspx

Also note that there are quite a few fixes included in SP1 plus the post SP1 rollups KBs 941422 and 948945 and 950279.

http://support.microsoft.com/kb/941274

http://support.microsoft.com/kb/948945

http://support.microsoft.com/kb/950279

There are two KBs that are specific to Content Deployment with 60+ fixes. If you have having serious CD problems, you'll need to talk with Customer Support Services to obtain these:

http://support.microsoft.com/kb/952698 

http://support.microsoft.com/kb/952704/

In theory these two are a rollup of all the previous Content Deployment hogfixes. I am still trying to confirm that this is true.

SharePoint Designer Check-in and Check-out and Publishing

Maybe I'm missing a hotfix or something, but SharePoint Designer seems to have a lot of problems with Check-ins and Check-outs. Often it shows a file as checked out when it is actually checked in and vice versa. Sometimes closing SD and opening the site again clears this up, but as a general practice, I do a lot of check-ins and check-outs in the browser and not in SD.

Mostly I'm talking about Master Pages and Layout Pages - which you can check-in and check-out in your browser by navigating to the Master Pages Gallery found under Site Settings > Galleries > Master pages and page layouts

Also, I typically use the Publish Selected Files functionality to promote new Master Pages and Page Layouts from Dev to Production, but note that you have to check out the files on both servers. The easiest and most effective way to do this again is in the browser by navigating to the respective Galleries on each farm and checking them out in the browser.

For instance, you go to the Master pages and layouts Gallery on production and check-out your custom master page, and you go to the Master pages and layouts Gallery on development and you check-out your custom master page, and then on Dev in SharePoint Designer you right click on your custom master page and select Publish Selected Files (and enter the url for your production site if you haven't already).

Note that after you Publish your new versions, they are only minor versions, and you can view them on production without endangering the site for other users. Once you confirm that they are working and doing what you want, then you can Check them in as a Full version on production. Remember also then to Undo Checkout on Dev. You only checked it out to publish it, so just Undo Checkout so that you don't have a new insignificant version.

To review - after Publishing, on Production after checking them as a Minro Version you check in and approve a Major Version, and then on Development you Undo Checkout.

A little complicated, but it works consistently.