I generally dislike nullable columns, lots of nulls usually mean a poor design, however, sometimes you don't always have all the data - and lets not forget about apps that create new rows by inserting a blank row with the PK ( usually a guid )  and then update the newly created row.

So if you don't have all the data you need a value , maybe null or maybe a default, such as 'not set' or 'unknown' etc.etc.

I'm slightly confused about the overwriting of a default, a default is usually used to give a value where one is not provided at the time, for instance a blood group ( well I figure not all people know their blood group ) in a doctor's system.  The defaults such as dates, userid or such - why would you overwrite them - your documentation and data dictionary should cover this and your test and release process catch any issues. ?

Masking with views is a interesting approach to combine with defaults though unwieldy I guess, you need an 'insert' view and an everything else view. Colin, I'm kinda with you, except in practice not everyone has a data dictionary (or reads it). It is perhaps an interesting thing to scan for before applying a change, looking to see if they are overriding a default.

I appreciate the comments, wasn't sure how this topic would be received!

For those interested, here is the link Joe mentioned: http://www.dbazine.com/ofinterest/oi-articles/celko35

Joe, it's an interesting technique and one I haven't applied at the db level - yet! I'll be looking for a place to try that out. But I'd be curious to hear more from you about pro/con of using defaults.