This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
I guess an agile database would be funny.(Aren't they, anyway? Most databases have paths a migratory bird would envy!) Anyway wouldn't a database be just a by-product of an agile process ? Unless special attention needs to be paid to roles and support required from the DB guys in an agile process ?
Joined: Jan 23, 2002
Anyway wouldn't a database be just a by-product of an agile process ?
Well, depends on what you mean by a "database". Most projects end up using an abstract database of some sort, be it a cluster of Oracle servers or a plain old file system. Few projects produce a relational database software as a by-product, however
Unless special attention needs to be paid to roles and support required from the DB guys in an agile process ?
Ideally, the "DB guys" are part of the agile team, not in a support role. In that way, yes, special attention should be given.
Originally posted by Pradeep Bhat: What does [agile database design] mean?
Scott would surely give you a more accurate description, but here's how I would classify agile database design: The database schema is designed in small steps using an evolutionary approach, based on emerging needs during the whole software development life-cycle. (Am I close?)
The database schema is designed in small steps using an evolutionary approach, based on emerging needs during the whole software development life-cycle.
Why do we call it agile when it is done in small evolutionary steps ?
Joined: Jan 23, 2002
Originally posted by Pradeep Bhat: Why do we call it agile when it is done in small evolutionary steps ?
I guess we could call it evolutionary database design just as well. However, agile does have more punch in it to stress that the evolution needs to happen fast when a need arises, i.e. the iterations should not be in the months.
It's actually called Agile Database *Techniques*. It's about techniques to do database development in an agile way as described by the values and principles of the Agile Manifesto. It has much to do with how the whole team works together and as such a process issue.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Good questions, with several answers. ;-) 1. We need to distinguish between the Agile Data (AD) method and agile database techniques (ADT) which support the methdod. The method, http://www.agiledata.org/essays/vision.html, defines 6 philosophies for effective data-oriented activities on agile projects. The techniques, described at www.agiledata.org as well, support the method. It would be irresponsible of me to define a method without supporting techniques. Fundamentally this is a process+ discussion. 2. The fundamental message to data professionals is that modern development is evolutionary (iterative and incremental) in nature and therefore you need to work in that manner as well (and by the way, here are the techniques that enable you to do so). 3. The fundamental message to developers (object professionals, call it like it is) is that data is important and you need to improve your skillset. Naturally I also cover the basic skills you need, such as data modeling and data normalization, so you have an understanding of the fundamentals. But I also get into implementation issues, such as how to implement concurrency control in your Java code. This chapter covers the basics of CC and describes several strategies for implementing it, discussing the trade-offs. Most books only focus on one strategy, such as doing an incremental counter to support optimistic locking, but my philosophy is that effective developers know several ways to do things and will pick the right approach for the situation. You don't want to be a one trick pony, do you? 4. Data folks should be part of the team. As I've discussed in other postings, they should be generalizing specialists. Over time, if they do this, they'll likely rethink the concept of being just a data professional and think of themselves. 5. Database design can and should proceed in an evolutionary manner, just like object design. And, when you actually try it, it seems to work much better this way. Many experienced data folks might not see it this way, but then again they very likely haven't tried the new ways either. - Scott