Comments on: Agile Database – Part 1: The release problem http://warren.mayocchi.com/2006/03/29/agile-database-part-1-the-release-problem/ Life, Software Development, Creativity: What I care to write about Fri, 09 Jul 2010 16:14:02 -0400 http://wordpress.org/?v=2.8.6 hourly 1 By: warren http://warren.mayocchi.com/2006/03/29/agile-database-part-1-the-release-problem/comment-page-1/#comment-9370 warren Tue, 14 Apr 2009 12:23:01 +0000 http://www.mayocchi.com/blog/2006/03/29/agile-database-part-1-the-release-problem/#comment-9370 <p>Re: Person_name...what about simple web registations (name + email)?</p> <p>It is a subjective call as to whether a change is a real world refactoring or an omission by the original designer. Some examples from my work:</p> <ul> <li><p>Today I was adding 'ROWDEPENDENCIES' to tables that were not created with that clause (an infrastructure technology change provides for a 'changestamp' feature that was once implemented via custom code).</p></li> <li><p>I have worked regularly with legacy systems that contain overloaded fields similar to the person_name example. Pretty much an anti-pattern now, but still out there.</p></li> <li><p>Adding new features to a system in a second phase of development (features which require a new set of tables).</p></li> <li><p>Altering existing tables to add extra attributes that were not required in initial project iterations.</p></li> <li><p>Changing the length/precision of a field to reflect the latest information (that was not available or expected in the intial design).</p></li> <li><p>Moving from a 1:1 relationship with an attribute (stored in the base table as another column) to a 1:many relationship (stored as an intermediate relationship table). Again this example was due to a change in the intial requirements.</p></li> </ul> <p>It can be (and is) argued that all changes should have been identified completely up-front. However, whatever our approach to software development, change happens. We use our design skills and experience to minimise bad data modelling in any case. When using an adaptive approach like agile, it is also important to have the tools to release a little part of the system and build on it. Change in an agile environment with good data modelling can be as simple as an incremental release of database features.</p> Re: Person_name…what about simple web registations (name + email)?

It is a subjective call as to whether a change is a real world refactoring or an omission by the original designer. Some examples from my work:

  • Today I was adding ‘ROWDEPENDENCIES’ to tables that were not created with that clause (an infrastructure technology change provides for a ‘changestamp’ feature that was once implemented via custom code).

  • I have worked regularly with legacy systems that contain overloaded fields similar to the person_name example. Pretty much an anti-pattern now, but still out there.

  • Adding new features to a system in a second phase of development (features which require a new set of tables).

  • Altering existing tables to add extra attributes that were not required in initial project iterations.

  • Changing the length/precision of a field to reflect the latest information (that was not available or expected in the intial design).

  • Moving from a 1:1 relationship with an attribute (stored in the base table as another column) to a 1:many relationship (stored as an intermediate relationship table). Again this example was due to a change in the intial requirements.

It can be (and is) argued that all changes should have been identified completely up-front. However, whatever our approach to software development, change happens. We use our design skills and experience to minimise bad data modelling in any case. When using an adaptive approach like agile, it is also important to have the tools to release a little part of the system and build on it. Change in an agile environment with good data modelling can be as simple as an incremental release of database features.

]]> By: Steven Macleod http://warren.mayocchi.com/2006/03/29/agile-database-part-1-the-release-problem/comment-page-1/#comment-9320 Steven Macleod Mon, 13 Apr 2009 10:17:04 +0000 http://www.mayocchi.com/blog/2006/03/29/agile-database-part-1-the-release-problem/#comment-9320 <p>Hi, just getting my head around Agile DB development. I am sure your example above is given as a simple example but surely you would have to be really dumb to create a field called Person_Name in the first place. This may appear to be an obnoxious comment, but all the examples I see around Agile refactoring are for refactoring really stupid mistakes, eg breaking 1NF as in this case. It seems from what I have read that the Agile method uses refactoring to solve problems caused by really bad data modelling, whereas Agile should be used to avoid these errors in the first place. </p> <p>I would be interested in your thoughts on this and would be interested in any real world examples of refactoring complex changes that could not have been preconceived at the modelling phase.</p> <p>Regards</p> <p>Steven</p> Hi, just getting my head around Agile DB development. I am sure your example above is given as a simple example but surely you would have to be really dumb to create a field called Person_Name in the first place. This may appear to be an obnoxious comment, but all the examples I see around Agile refactoring are for refactoring really stupid mistakes, eg breaking 1NF as in this case. It seems from what I have read that the Agile method uses refactoring to solve problems caused by really bad data modelling, whereas Agile should be used to avoid these errors in the first place.

I would be interested in your thoughts on this and would be interested in any real world examples of refactoring complex changes that could not have been preconceived at the modelling phase.

Regards

Steven

]]>