When providing a GUI to create new and edit existing objects in a system,
rather than have separate data entry forms for these operations, have the
Create New operation create an empty object and immediately invoke the Edit Object operation on the object. 

'' Do you mean some people '''don't''' do this?''
----
I had a student who created separate create and edit forms for each entity in her project. BTW, she came from a VMS background. I don't know the significance of this.
----
Filling in forms can be tedious. Sometimes, some defaults are provided, but more could be done in that respect. Often, only partial validation is done. Some forms don't allow for the possibility that the user wants to provide some of the data now, and the rest on another occasion. Also, many systems will skip validation almost entirely, subject to approval. This leads to such approval being given inappropriately by someone who has misunderstood the nature of a problem. And why can't help messages be more useful... and customizable?
----
The problem people might have with 'create then edit' as opposed to 'fill in details then create' is that the created object in the first instance may violate 'not null'- style constraints in the object. I'm not saying the pattern is wrong. As the previous comment points out, this prevents incorrect information being saved in a draft form before fixing it. 

The problem gets worse when batch-loading data. You end up with data outside the system that needs corrected, (through some 'different' UI) as opposed to having the non-validated data in the system, then validating as a separate step in order to make sure the data is up to snuff for processing. Once you've made this small step, it becomes clearer that validation is actually ensuring preconditions for a process, and is not necessarily a static set of constraints as in most RDBMS. An example: given a classified ad with a partial address, a data cleanse process has 'valid enough' data to match an address record in a database. Given an address record, a GIS system has 'valid enough' data to return the advert as part of a search for ads in the local area. Failing to do the data cleanse would mean messing with the GIS system to recognize the duff address and probably affecting its performance. Failing to allow the ad into the system without a complete address record would mean providing 2 guis for your customer service to process ads, delays in processing, and lost revenue. 

So, to sum up: data can be valid on many levels, and I reckon its the assumption that it is just a boolean that leads to people avoiding 'CreateWithImmediateEdit'.
----
I think that even in those situations it is a good idea to add a "state" field to the record
that indicates the validity level of the record itself. Having one function to set all the field values of the record seems to be a big win in terms of maintenance of code.
----