Passionate about data

Data and its implications on software design and development.

When Does Evolutionary Design Happen?

A question I get, mostly related to the evolutionary database design and development. When the pair (team) gets a new feature (story) to work on, the team looks at the existing table/database design and sees if the current design is enough to implement the feature they are working on. If the currency database design does support the feature they are trying to implement, then they do not have to change the database at all, they will move on to implement the feature and change the application code as necessary. If the current database/table design does not allow them to implement the feature that they are trying to complete, then they start looking at how to change the database/table design so that they can implement the feature.

Without getting into the discussion of what is the correct design, I wanted to highlight how the design decision is made.

Lets take a example: The feature Joe and Andy (pair) are working on is “As a Customer I should be able to have billing and shipping address”. Now to implement this feature Joe and Andy see if the Customer has the ability to store any addresses, if we can store addresses, if we have address table etc.

Joe and Andy find out that they have a Customer table and an Address table, also that Customer table has a AddressID on it, which shows the CustomerAddress. Joe and Andy decide to create two more attributes/columns on the Customer table named BillingAddressID and ShippingAddressID and remove the previous AddressID, copying the data from AddressID to BillingAddressID as well as ShippingAddressID, changing the AddressID makes for better column name.

So Joe and Andy implemented the following refactorings.

Introduce New Column (ShippingAddressID) Introduce New Column (BillingAddressID) Move Data (AddressID to ShippingAddressID and BillingAddressID) Add Foreign Key Constraint (ShippingAddressID depends on Address table) Add Foreign Key Constraint (BillingAddressID depends on Address table) Drop Column (AddressID)

Now they go on to implement the rest of the feature in the Application, I find that one pair (Joe and Andy in our example) working from the UI layer down to the database layer touching all the layers of the application makes for much more sense than having one pair work on the database side of things, another on the domain layer and then another on the UI layer. This allows for the team to learn all aspects of the application and also makes everyone productive and not wait on team to finish their part before starting to work on our feature. When you are lacking in certain skills, you can always pair with the Expert in the given area. If Joe and Andy thought they need help writing the data migration script for the above refactorings, then they would pull the data expert on the team and then pair with him. This is how collaborative and evolutionary design happens.