Scott Bellware of CodeBetter.com has a great article on CoDe Magazine about agile development and how it improves the whole development lifecyle.  He has this to say about the old way of running a development project:

Somewhere in the lost pre-history of software development, some mythical programmer archetypes chose how the generations of programmers that would follow did software development. They would choose between defined process control and empirical process control. Their choices may have been appropriate to their work at the time, but here in the present-day software development world, we’re doing little more than mechanically following the kind of professional superstition that kept 15th century sailors from sailing off the edge of the world to be snapped up by one of the elephants on whose backs the flat Earth sat, or by the giant turtle on whose back the elephants stand.

Where would we be without Great A’tuin, Berilia, Tubul, Great T’Phon, and Jerakeen?

Anyway, his point is well made & goes well with the recent podcast by the DotNetRocks guys where they interviewed Scott Ambler from IBM on agile development. Scott talked about agile database development, in fact he’s got a book about it. One thing he mentions is how difficult it is to make even simple changes to a production database:

“If I ask you to go back to work tomorrow, and what I’d like you to do is rename a column in a production database, can you safely do that and roll into production in less than a day?” It’s amazing, very few people can. And I mean, and as soon as you’re asking so how long it will take, and some people can do it in a month and some people can do it in three months, some people would think it’s so risky, they wouldn’t even try to attempt it. So, my point is that well, first of all, renaming a column, is an absolutely trivial thing and trivial things should be trivial.

It takes us about a day, including testing in staging.

Also on databases, DNR also have an interview with Allan Hirt on providing high availability with SQL Server 2005 which is highly recommended if you’re responsible for maintaining production Sql Server 2005 servers.

And to cap off this list with a rant that is close to my heart, Jeremy Miller tells it as it is about composite keys:

There’s a section in Eric Evans’ DDD book where he spends about 3-5 pages saying that composite keys are bad and surrogate keys are good (without just coming out and saying that).  At the time I thought he was being exceptionally wordy, but it’s an awfully good point to drive home.  Composite keys (multi column primary keys) make any kind of Object/Relational mapping and persistance in general harder.  Life is so much easier with surrogate keys.  You can always make unique constraints where it’s necessary. 

And in case you were wondering, the Eric Evans book he’s talking about is Domain-Driven Design: Tackling Complexity in the Heart of Software.