At the end of last week Tom and I made a change to one of the files in the system (that would translate to one or more tables for you relational types) so that it was keyed by an auto-increment key rather than the one I originally designed. How much fun is it to change something like the primary key to a file when you have software written that reads and writes it, and test data already populating the file? Well, yeah, not a lot.
I’ve read Refactoring Databases: Evolutionary Database Design by Ambler and Sadalage. Fortunately, it is typically easier for us using Cache’ or any MultiValue database to do most types of database redesign required, than with a typical RDBMS (Relational Data Base Management System).
It isn’t necessary to nail down a complete database design in advance of other development efforts, as some teams have attempted. With an agile approach to development there is a focus on coding only those aspects of the software required to add the specific user functionality tagged for this iteration of code. There are probably as many strategies and philosophies in this regard as there are developers, and I bounce among a few of them.
My goal right now is that while being agile in our efforts (we aren’t, but we are trying), we not proceed to build a house with a slab foundation and then find that we need to add a basement later. It makes sense to me to add another bedroom if we need one, perhaps replace the roof, if required, even to “refactor” the plumbing at some point, and surely to swap out the appliances and countertops, but I really don’t want to have the cost and risk of digging and pouring a basement for an existing house that lacks one if we can avoid it.
There are so many unknowns, however, that I do not think my i’s are dotted in this regard. I think we will have many times in the future when someone will ask for an enhancement that will sound to me like they said “Hey, let’s add a basement.” I have to encourage myself to move forward with an agile approach anyway, in spite of all of the possible basement-like requirements that might be headed our way.
We have high level use cases and many open tickets, but in spite of our scrum-like Saturday meeting (with one week in our project equal to one scrum day), as a team do not have a really clear set of features to be added this coming week. I wanted to get there, and those working on web pages have a better sense than those assigned to Amazon e-commerce, which right now is a cloud for us. [By the way, if you ever wonder whether I am playing with words, I likely am.]
I think I need to be better at jumping in and doing something, specifically right now on the e-commerce front, rather than thinking too hard about it. Perhaps instead of working to avoid large amounts of rework in the future, I should embrace the notion of pouring basements at the point when we realize that a basement needs pouring?