FDD or DDD not BDUF

David Anderson's post about the roots of FDD started me off on a trip down memory lane: I fondly remember receiving the Coad Letter by email, hearing Peter Coad in person talking to the BCS about "Modelling in Colour", and being inspired by a "Better Software Faster" workshop run by Andy Carmichael. All of which probably makes it apparent that I believe in constructing models as an important part of a software development process.
Modelling has unfortunate "Big Design Up Front" connotations though, despite people like Scott Ambler and Eric Evans demonstrating that it doesn't have to be that way. These kind of models - the small-in-ambition ones that help us to turn stories into code via specific test cases - have remarkably similar characteristics to the programming languages described as "New Jersey style, not MIT/Stanford style" in The Rise of Worse Is Better: the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained.