SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


On Database Migrations and Agility


On Database Migrations and Agility

Author
Message
Phil Factor
Phil Factor
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2716 Visits: 2984
Comments posted to this topic are about the item On Database Migrations and Agility


Best wishes,

Phil Factor
Simple Talk
ganotedp
ganotedp
SSC Rookie
SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)SSC Rookie (35 reputation)

Group: General Forum Members
Points: 35 Visits: 202
The not-so-flattering Agile analogy (not invented by me) is like trying to build a house one-room-at-a-time (where software is the "fine carpentry and dry wall" and data structures are the "foundation and roof"). "O, wow, I really like this kitchen" says the customer, "let's add a bedroom". Seems easy if you're doing fine carpentry and drywall. However, how do you do Agile foundation work and roofing? Brings to mind the parable told by the radical rabbi about the foolish man building his house on sand. The wise man built on a solid foundation.
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)

Group: General Forum Members
Points: 114216 Visits: 41367
It therefore always surprises me when Application programmers tell me that all 'Agile' techniques are directly applicable to database development.


Heh... what did you expect, Phil? Many application programmers and their managers have misinterpreted the Agile Manifesto as meaning there doesn't need to be any documentation or preparation and have also misinterpreted what Knuth said about pre-optimization being the root of all evil. With exceptions, of course, most of the application programmers that I've met and worked with personally all think the same thing... disk space is cheap, machines with more memory are coming, stored procedures are an evil to be avoided, and an RDBMS is just a place to store data.

As a very interesting (to me, anyway) sidebar, I'm currently working with 3 wonderful Application Developers that have seen the proverbial light and actually get it. Like the song says, "I'm in Heavennnnn!" I think that part of the reason why they get it is because they're the ones that have to clean up after their "Agile/No Pre-Optimization/Design-on-the-fly" predecessors.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Phil Factor
Phil Factor
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2716 Visits: 2984
The Agile stuff ain't new at all. I worked in a CSC team in the Nineties practicing some techniques that were recognizably 'Agile'. The only difference was that we used Big sheets of paper stuck on the walls with Blu-tac rather than post-its and called the meeting 'shirtsleeve meetings'. I was in the Data Architecture team and we insisted on getting the data architecture planned out in its entirety before the coding started. It was the only part of the project that got finished, all beautifully mapped out in ERwin.


Best wishes,

Phil Factor
Simple Talk
Greg Edwards-268690
Greg Edwards-268690
SSCrazy
SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)SSCrazy (2.1K reputation)

Group: General Forum Members
Points: 2092 Visits: 8533
Jeff Moden (1/8/2012)
It therefore always surprises me when Application programmers tell me that all 'Agile' techniques are directly applicable to database development.


Heh... what did you expect, Phil? Many application programmers and their managers have misinterpreted the Agile Manifesto as meaning there doesn't need to be any documentation or preparation and have also misinterpreted what Knuth said about pre-optimization being the root of all evil. With exceptions, of course, most of the application programmers that I've met and worked with personally all think the same thing... disk space is cheap, machines with more memory are coming, stored procedures are an evil to be avoided, and an RDBMS is just a place to store data.

As a very interesting (to me, anyway) sidebar, I'm currently working with 3 wonderful Application Developers that have seen the proverbial light and actually get it. Like the song says, "I'm in Heavennnnn!" I think that part of the reason why they get it is because they're the ones that have to clean up after their "Agile/No Pre-Optimization/Design-on-the-fly" predecessors.


Amazing what happens when confronted clean up is involved.
Kind of like when I ground boxes on the floor, and then started to weld.
Every welder should have to grind their own welds.
It tends to improve the process.Hehe
GSquared
GSquared
SSC-Dedicated
SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)

Group: General Forum Members
Points: 30051 Visits: 9730
The point of Agile is to allow business rules in the software to evolve as business rules in the business evolve.

There are ways to build a database to allow for ease-of-evolution, and hence Agile databases. Ironically, they require even more up-front planning and homework, not less.

But what most developers mean by "Agile" is actually "Cowboy". Database development can be quite Agile. It creates a horrible mess when it's done Cowboy-Coder style.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)SSC Guru (114K reputation)

Group: General Forum Members
Points: 114216 Visits: 41367
GSquared (1/9/2012)
But what most developers mean by "Agile" is actually "Cowboy".


Hear here!!! GUS FOR PRESIDENT!!! :-D

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Peter Schott
Peter Schott
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1810 Visits: 1920
We do Agile dev in our shop and spend a decent amount of time planning DB changes up-front to avoid doing it over as we move forward. Sometimes we overplan, sometimes underplan, but it helps to at least attempt to get it right up-front. It helped once the team finally understood that you couldn't just drop tables and create new ones like you can with DLLs and EXEs. It took a while for that to sink in, but they understood it and it helped us handle DB migrations a little better in the future. There are still times we need to do a large data operation the night of a release, but on the whole knowing that helped us make better plans for the future. Finding the correct balance of "just enough" as opposed to "plan it as far out as we can" can still be challenging, but having the team backing up those decisions makes a huge difference.

I actually like the Agile plan when it can work. I've seen too many large DB Projects fail due to using waterfall (think Amazon Falls) methodology and then years of work to deliver the finished project. I'd much rather start small enough to show something and get feedback as we go. That helps us make course corrections and tackle more important needs as they come up instead of delaying them further.
Dream Weaver
Dream Weaver
SSC-Enthusiastic
SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)

Group: General Forum Members
Points: 142 Visits: 315
ganotedp (1/7/2012)
The not-so-flattering Agile analogy (not invented by me) is like trying to build a house one-room-at-a-time (where software is the "fine carpentry and dry wall" and data structures are the "foundation and roof"). "O, wow, I really like this kitchen" says the customer, "let's add a bedroom". Seems easy if you're doing fine carpentry and drywall. However, how do you do Agile foundation work and roofing? Brings to mind the parable told by the radical rabbi about the foolish man building his house on sand. The wise man built on a solid foundation.


I wanted to write a more lengthy response to this analogy than would be appropriate in this space. You can find it at: http://surroundingthecode.wordpress.com/2012/01/22/agile-development-the-wrong-analogy-again-how-about-this-one



Evil Kraig F
Evil Kraig F
SSChampion
SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)

Group: General Forum Members
Points: 10609 Visits: 7660
Peter Schott (1/11/2012)
I actually like the Agile plan when it can work. I've seen too many large DB Projects fail due to using waterfall (think Amazon Falls) methodology and then years of work to deliver the finished project. I'd much rather start small enough to show something and get feedback as we go. That helps us make course corrections and tackle more important needs as they come up instead of delaying them further.


I agree with this (having been wandering amongst a few agile teams of late) but with a caveat. The powers that be must understand that you WILL require entire sprints for re-design of the core module to integrate new work. It's not an optional choice. This will require downtime when the fixes are put into place.

With that caveat, I agree you can modularly build databases within the agile structure. However, I also agree with Gus. I've seen too many shops that got their prod powers removed and suddenly Agile is 'problematic'. It's all to often a Cowboy mentality.


- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search