Change is coming to how we get the radio we listen too. Radio listeners will go from having 10 choices on their radios to thousands. Good times, good times.

Thursday, January 19, 2006

Agile schema

I like to start with a database layout when building up a new site, but I go for the minimalist approach. Trying to flush out every table, and every column is right back to the waterfall model of software development. Agile development demands that you do only what is necessary to make the current test pass. If that means having a cusomer table with just an "id" and "name" field, so be it. With TDD its easy to flush out the db design as work progresses. There will be time to add address, phone, and bra size for a customer later. Its even easy to shut down a model and move its pieces around. Its true that changes like this tend to have concequences far and wide, but with tests in place, its easy to know what code needs to be massaged.

The idea is to hold off making structure decisions until the last possible minute. Once a data schema is set, it can get inflexible, even with good tests in place. I want to always leave the maximum amount of flexibility until I have no choice.

Example - does the "first name", "last name" fields go in the customer table, or the credit card table, or both? I've built apps all three ways, and untill you've gotten a lot of use cases, flushed out those cases, and even rewritten them with the user, it can be difficult to know which one is proper.

No comments: