Comments on: Agile and SQL links http://blog.slaven.net.au/archives/2007/02/04/agile-and-sql-links/ Wed, 17 Mar 2010 02:53:50 +0000 hourly 1 http://wordpress.org/?v=3.0-alpha By: SqlServerForum.org » Blog Archive » Agile and SQL links http://blog.slaven.net.au/archives/2007/02/04/agile-and-sql-links/comment-page-1/#comment-74726 SqlServerForum.org » Blog Archive » Agile and SQL links Thu, 08 Feb 2007 07:42:47 +0000 http://blog.slaven.net.au/archives/2007/02/04/agile-and-sql-links/#comment-74726 [...] post by Glenn Slaven and software by Elliott Back Share and Enjoy:These icons link to social bookmarking sites where [...] [...] post by Glenn Slaven and software by Elliott Back Share and Enjoy:These icons link to social bookmarking sites where [...]

]]> By: Glenn Slaven http://blog.slaven.net.au/archives/2007/02/04/agile-and-sql-links/comment-page-1/#comment-118475 Glenn Slaven Mon, 05 Feb 2007 15:23:57 +0000 http://blog.slaven.net.au/archives/2007/02/04/agile-and-sql-links/#comment-118475 60+ servers? Wow, I would hate to be your DBA! 60+ servers? Wow, I would hate to be your DBA!

]]> By: Scott http://blog.slaven.net.au/archives/2007/02/04/agile-and-sql-links/comment-page-1/#comment-118474 Scott Mon, 05 Feb 2007 14:56:47 +0000 http://blog.slaven.net.au/archives/2007/02/04/agile-and-sql-links/#comment-118474 It is much easier to rename a column when all you got is one production site, a testing site and a few development sites. In our case, changing a column would require<br><br>- Change a column in the table definition file<br>- Write an upgrade script and test it against trunk + 2 branches<br>- Rebuild the 2 release branches<br>- Test the new builds <br>- Get permission from clients who need the change about upgrading<br>- Push out the change across 60+ servers in the evenings<br>- Send the patches + upgrade instructions to clients who are not hosted with us<br>- Wait for the support calls in the morning when clients found some incompatibility :)<br><br>Around a week of work, and we are already trying to be as agile as possible :(<br><br>Moreover, I found when the development only involves micro-iterations, people are less likely to work on re-factoring and re-architecturing the code, which are usually necessary when you are looking at 5+ years into the project... It is much easier to rename a column when all you got is one production site, a testing site and a few development sites. In our case, changing a column would require

- Change a column in the table definition file
- Write an upgrade script and test it against trunk + 2 branches
- Rebuild the 2 release branches
- Test the new builds
- Get permission from clients who need the change about upgrading
- Push out the change across 60+ servers in the evenings
- Send the patches + upgrade instructions to clients who are not hosted with us
- Wait for the support calls in the morning when clients found some incompatibility :)

Around a week of work, and we are already trying to be as agile as possible :(

Moreover, I found when the development only involves micro-iterations, people are less likely to work on re-factoring and re-architecturing the code, which are usually necessary when you are looking at 5+ years into the project…

]]> By: Glenn Slaven http://blog.slaven.net.au/archives/2007/02/04/agile-and-sql-links/comment-page-1/#comment-73829 Glenn Slaven Sun, 04 Feb 2007 23:23:57 +0000 http://blog.slaven.net.au/archives/2007/02/04/agile-and-sql-links/#comment-73829 60+ servers? Wow, I would hate to be your DBA! 60+ servers? Wow, I would hate to be your DBA!

]]> By: Scott http://blog.slaven.net.au/archives/2007/02/04/agile-and-sql-links/comment-page-1/#comment-73824 Scott Sun, 04 Feb 2007 22:56:47 +0000 http://blog.slaven.net.au/archives/2007/02/04/agile-and-sql-links/#comment-73824 It is much easier to rename a column when all you got is one production site, a testing site and a few development sites. In our case, changing a column would require - Change a column in the table definition file - Write an upgrade script and test it against trunk + 2 branches - Rebuild the 2 release branches - Test the new builds - Get permission from clients who need the change about upgrading - Push out the change across 60+ servers in the evenings - Send the patches + upgrade instructions to clients who are not hosted with us - Wait for the support calls in the morning when clients found some incompatibility :) Around a week of work, and we are already trying to be as agile as possible :( Moreover, I found when the development only involves micro-iterations, people are less likely to work on re-factoring and re-architecturing the code, which are usually necessary when you are looking at 5+ years into the project... It is much easier to rename a column when all you got is one production site, a testing site and a few development sites. In our case, changing a column would require

- Change a column in the table definition file
- Write an upgrade script and test it against trunk + 2 branches
- Rebuild the 2 release branches
- Test the new builds
- Get permission from clients who need the change about upgrading
- Push out the change across 60+ servers in the evenings
- Send the patches + upgrade instructions to clients who are not hosted with us
- Wait for the support calls in the morning when clients found some incompatibility :)

Around a week of work, and we are already trying to be as agile as possible :(

Moreover, I found when the development only involves micro-iterations, people are less likely to work on re-factoring and re-architecturing the code, which are usually necessary when you are looking at 5+ years into the project…

]]>