Why do most database developers dislike Agile as a project management methodology?

Question

To me "Agile" methodology is a common-sense oriented approach and one that should likely be adopted for most software projects. I find that while a lot of Middle Tier Developers and Front End developers find it a very sensible project delivery model, plenty of Database developers (and good ones) seem to be totally against it. They are very keen on knowing the biggest picture and designing a database solution that will cater to that.

They do not seem to like "Vertical striping" of a functionality. They would rather see the complete design document/feature document instead of concentrating on small user stories.

Sarcasm aside, can someone realistically provide some insight as to why this mentality is prevalent? Especially DB devs? How would an agile methodology benefit database development?

Answer 1

DB Developers like to have the whole picture up front so they can design the most robust, performant solution possible.

Adding functionality to the UI, Business Layer, or Back End are typically pretty easy.

Adding functionality to a Database could cause a complete re-design to be required when that re-design could have been prevented up front by knowing the entire set of requirements rather than a sub-set.

Answer 2

Maybe database developers in particular dislike small, iterative releases because changes to data structure are generally more involved than changes to an application. Since our default toolset lacks dependency tracking and solid unit testing, I'm always concerned when we make changes to our data structure - so much so, that we'll often add to our structure instead of taking on the risks involved with making changes to something existing.

It's always easiest to have the big picture up front, but I'd have to vote for lack of solid unit testing and stability assurance as a reason that Database Developers oppose tight iteration methodologies like Agile.

Answer 3

Because refactoring a program requires making only code changes. Refactoring a database, in any significant way, is going to require making changes to concrete data.

Therefore, using agile techniques in database development is somewhere between using agile techniques in coding ("let's split this class into two, declare a new enumeration there, and a new singleton class here") and using agile techniques in building a house ("let's make two bedrooms instead of the one we have now, move a couple of windows, and provide two electrical circuits where there was one before").

Answer 4

For most applications, database developers are overkill.

For applications large enough to merit database specialization, you're at larger companies, where the database folks have been around longer than web work. Change is scary.

Answer 5

For an example. Three weeks into a project a certain table has been created that is called by X number of stored procedures, views, etc.

Adding a single column affects all of those items. Schema changes are not always caught as errors or exceptions.

Using an IDE typically allows you to compile your code and view missing references, mis-typed and mis-named properties. You can slash and burn your way through changes. Unfortunately, I have never worked on a project where the database schemas and their uses were so well documented after each change as to anticipate where cascading changes are to be made.

Adding/removing columns may also affect decisions regarding indexing and normalization. What was once a free form text box could now be a select box with a lookup. This means changing the column on the original table, and then creating a new list of lookup values (table) along with the relationship between the tables. If there is data already present in the original table, this is at least a nuisance, at most it can be a time consuming process.

These are just common simple examples. I have seen far more complex ui changes that require introduction of hierarchies which end up as almost complete database rewrites.

Also in most of the Agile articles I have read, there seems to be a discussion on how to best tackle data integration, so I do not think it is only a bunch of grumpy SQL developers an DBAs holding on to the old waterfall method.

Answer 6

If you make change to an application, it's easy to roll out the code or application to the users with minimal disruption. If you have to make changes to a database, even a simple thing like changing an index, that can take hours, perhaps tens of hours, to rebuild the indices, and then during that time, the database may be very slow to the point of being inaccessible.

And because it's relational, changes can often affect a lot of other things. You might have to re-write all your views, for example. It's a real PITA to change things frequently in a database. It doesn't help when developers want to make changes willy-nilly, don't consider the costs of doing it ( because the DBA does all the changes and does the grunt work ) and then the next week they want to undo it and do something else.

A race car driver may have no problem changing the timing of the engine every time they go around the track, but a chief librarian doesn't want to change the method for shelving books every week. The last lap doesn't matter. Making sure that you can find any book at any time in the stacks the the whole point of the library.