Q:

Is continuous creation and deletion of tables a sign of an architectural flaw?

Recently I had a discussion with a developer who mentioned that during program development, they routinely create and delete tables and columns on a regular basis while working on new features and justified things by saying that this is normal when using an agile development process. 
As most of my background is in a waterfall development environment, I wonder if this is actually considered proper under agile development, or if this might be a sign of an underlying problem, either with the program architecture or with their following of the agile process.

A:

It's becoming more-and-more apparent to me every day that "agile" is becoming a synonym for poorly thought-out, chaotic, hurried and seat-of-your-pants. And none of those things are compatible with an Agile approach as I understand it.
Having an effective and repeatable Agile process is not easy, and I don't believe that it inherently reduces the total amount of work to be done even though it may very well lead to better products.
If they've said that they don't have time to "refactor" the database then they probably also don't have time to set up versioning and migration for the database. They probably haven't taken the time to create a suite of functional tests for it. All of those things are what I think of when I think of a solid Agile process that's headed for success.
In the end, Agile is just a word. What you are doing day-to-day determines if you'll be successful or not.

A:

While it is not unusual to create and drop tables as a design evolves, some cleanup might be in order to make sure your database is really using all those tables.
Yes, Agile is all about refactoring, but if they are now saying the system is too big to refactor, they have stopped doing Agile and are now just Cowboy programming.  The development team won't like being called that, but that is what they are doing.  Riding the range shooting anything that moves.
A DBA will help, just make sure you get a DBA that understands development as well as Agile development.  Your development team needs to be reined in, not thrown in jail.

A:

In general, often creating new tables and adding new columns is very normal in a process where programming and database administration are not strictly separated. A new feature might create new data that must go somewhere. Try too strictly to avoid that and you end up with an inner-platform model.
Well-written software hardly notices those new database objects, so nothing breaks just because of a new column in some table.
On the other hand, regularily droping columns or even tables is suspicious. A new feature never needs a table removed, so this could be a sign of people working completely planless.

