So on the fourth day I spent time at the following sessions:
- Creating Change One “Tic Tac” at a Time - “Alistair Cockburn”:http://alistair.cockburn.us/ and “Jeffery Fredericks”:http://www.agitar.com/
- Refactoring Databases : Evolutionary Database Design - “Scott Ambler”:http://www.ambysoft.com/ and “Pramod Sadalage”:http://databaserefactoring.com/PramodSadalage.html
Creating Change One “Tic Tac” at a Time
This session was very group oriented. Unlike some of the other sessions which involved roleplaying this session put about five to eight people at a table. The first goal was to discuss problem or obstacle that was overcome moving to some form of Agile practices. It could be a little win or a big win, but it had to be a win (Alistair and Jeffrey weren’t interested in the failures).
Each group had to vote and decide on a winning “win” for their group. Each “win” had to presented to the whole session audience. After everyone had heard all of the stories people were able to self-organize and go to the tables that had the “win” that they were interested in. Each table then had to discuss and list out the challenges and what led to them being overcome.
At the end Alistair and Jeffrey spent about 10 minutes going through some slides explaining the benefits of small tic tac changes rather then huge sweeping changes. They showed a nice graph which I haven’t been to find online yet. If anyone has a reference of it please send me a link.
What the graph portrayed was the effects of making changes and then benefiting from those changes. The idea is that for every change you make productivity goes down, and you stay in a dip and as you master the change your productivity goes back up and eventually surpasses your previous level of productivity. So this means:
- the bigger the change, the deeper the dip and the longer the dip drags out
- the smaller the change, the shallower the dip and the shorter you are able to surpass your old level of productivity
If you make a lot of small changes (one “tic tac”) at a time you end resulting getting a much higher level productivity in a shorter timeframe assuming each of your changes leads to better practices and higher efficiency. If you try to do too much you will be less productive then before and for a longer period of time. Alistair and Jeffrey believe that this is what causes so many teams who claim “Agile” failed for them.
Refactoring Databases : Evolutionary Database Design
Scott walked through the slides and Pramod did the real time demos. The “evolutionary” part of the discussion and probably their book, “Refactoring Database - Evolutionary Database Design”:http://databaserefactoring.com/ is more revolutionary to hard core DBAs who live a sheltered technical life which leads me to assume people from corporate america.
At the a technical level the presentation focused on:
- incremental changes to the schema
- versioning your database (rollback / roll forward features)
- testing your data (verifying your setup data)
- testing your interaction with the data (triggers, stored procedures, etc.)
- use source control
- developers should be able to check out and run a simple script which builds a development database for them
At a higher level the presentation focused on:
- developers pairing with DBAs and vise versa
- realizing that DBA is a different role, but not necessarily a different position
- doing better database practices all around
- communicating with the rest of the world
Scott has a lot of bundled up frustration with a developers, DBAs and “agile” people. He thinks there is too much of a barrier between developers and DBAs. He doesn’t like it when developers go around the DBAs because DBAs move too slow, although he recognizes that sometimes that’s just what you have to do. He seems somewhat ticked off about how “agile” developers focus on the practices during the application development, but that they slack when it comes to the database development. And this is going to get its own paragraph…
I agree with Scott when it comes to application development and database development. I think that too many developers consider the database a big dumb hash. At 40,000 feet I can agree with that analogy, but when you get closer to the ground the analogy stops working (with the current limitations of databases and disk storage mediums that we have today). Premature optimization is evil yes, but understanding SQL and how databases work isn’t premature optimization. Sometimes things that can be done in some simple SQL is more readable and faster to implement and test then the equivalent ruby or java code. Especially things which can be done with simple joins.
Back to the presentation…. Scott and Pramod are pushing for the same type of practices being used at the database level that are being used at the application level. Databases are archaic. SQL is archaic. It’s not elegant, but it’s still a very important piece to a lot of applications. Use the database when you should and test the hell out of what you’re doing. If you’re not using “Ruby on Rails”:http://www.rubyonrails.com one of the best advantages of its framework is its builtin database migration tools. Thee are also plugins like “Migration Test Helper”:http://spin.atomicobject.com/2007/02/27/migration-testing-in-rails/ which takes your testing of the database that much further.
After Refactoring Databases
I spent some time in the “Dungeon” where people were helping on creating a Rails web application for a non-profit group. I had some great discussion with “Paul Pagel”:http://www.8thlight.com/main/bios/paul from “8th Light”:http://www.8thlight.com and also “David Chelimsky”:http://blog.davidchelimsky.net/ who is one of developers for “RSpec”:http://rspec.rubyforge.org
blog comments powered by Disqus