Right now I am reading the book “Agile Samurai”, which many of you have read already. I’ve already covered about 60% of the book, and since my team has being agile for a while I do not expect any big surprises in the rest of it. I am not saying, that reading this book is useless, it’s just that I think I can share some thoughts about it, even although I am not completely through.
All these books which I recently read: Team Geek, Lean UX and now Agile Samurai talk essentially about the same concept: about not spending too much time on documentation, because it’s impossible to document everything before the actual work starts, about getting constant feedback from the customer, about being a team player, about willing to redo the work over and over, and other related things. Which is all understandable, however I keep thinking about the role of the database developer in this process, and how everything related to the database can fit into this technology.
The special role of the database is, and always will be to be a shared piece between different applications and at the same time to be an application of it’s own. And because if it’s dual nature there will be pieces of work which can’t be done in small increments. As my husband put it, when we were discussing this issue: you can’t fly an airplane in small increments, you need to left the whole thing in the air at once.
SOmetimes I am not sure, whether this is completely understood by Agile Masters :). In the Agile Samurai book one of the conversations between the Master and the Student is exactly about building the Data Warehourse, and the Master is quite clear about it. On one hand, he is saying that it is possible you won’t be able to deliver something in each iteration, on the other hand, he states, it’s bad. At some point you can’t help but wondering, whether all customers have ADD and just can’t wait?!
I remember how almost a year ago I was reading the Agile Database Development site, and found out, that everything what mentioned there was only a half-solution this way or the other. If you search for “Agile Database Development” on the web, you will find a lot of papers and presentations, but when you start reading them – it’s just Git, pgTAP, etc., but not really development technique….
For the past couple of weeks I am thinking a lot about the ways to actually make database development agile, to classify different types of database development, to identify, what agile means for all of them (mostly I am talking about database design vs. database functions and packages development, but not only that). I know, that 1) the quality of the database design can’t be compromised 2) we still should be ready to make design changes at virtually any time 3) or work around them 4) by means of creating functions and utilizing our super-natural optimization skills 🙂
… as the book says, “I will reflect more on this”.