JavaPolis 2005 – Agile Development

Another side of the software engineering coin is about the development process. The popularity of agile development is growing and therefore deserved the prominent attention at javapolis. Scott Ambler can be considered as one of the leading spokesmen of the agile movement and he took the opportunity to speak about some less familiar agile subjects like database refactoring and agile modelling.

Agile Model Driven Development

Beforehand, Scott warned us that he could be quite blunt with his statements …and he didn’t disappoint us. He told us that agile developers are often accused of hardly doing any requirements engineering, modelling and designing. Off course he denied this and instead argued that the traditional BRUF (big requirements up front) approach is not working because it often results in change prevention instead of change management and that it does not reflect reality. Scott argued that, during the initial phase of system design, it is almost impossible to have a good picture of the system and to make realistic requirements. However, we tend to ignore this reality and demand all the requirements up-front. So, an an endless list of requirements is made, just to be sure that everything that could be needed may be included (and still has many ommissions). Then we start modelling and we produce endless UML models that no one understands and uses (b.t.w. where is the use case for UML?) and during development we ‘discover’ that the models need constantly adjustments. Who are we kidding ……..?

Scott explained that agile modelling accepts the reality of uncertainty and change. Therefore we should model (and develop) incrementally, used prioritized requirements, ‘make our models just barely enough’ and have a lot of discussions about the requirements and functionalities. In addition, free-form diagrams, like white-board sketches, are often better suited than formal methods like UML.

Database refactoring

Changing a database model, like renaming a column, is a very hard task to accomplish. The difficulty is not the actual statement itself but that it can have an impact on many systems with unknown proportions. Therefore, DBA’s and database developers tend to be very conservative about datamodel changes. This is in contrast with the Java (and other) community that seem to embrace agile development to accomodate changing applications and Scott Ambler strongly suggests that the database community becomes more agile to support change. He also gave some suggestions: intelligent deployment strategy, system artifact versioning, regression testing and encapsulating database access. Since he was talking to a java audience he was succesfully doing some database bashing like ‘database people must adapt or they will be ignored’ and ‘why do we need a function like datamodeller while we would laugh about a sequence diagram modeller’, but he also had to admit that database refactoring shouldn’t be underestimated..
Fortunately, he also had some very serious suggestions about how we could support datamodelling. It basically narrows down to running both versions together for some time and use database features like triggers to keep the data synchronized. This is a very interesting idea that I haven’t seen in practice yet, but I am interested to try. But I am not convinced yet.
Although it was an interesting presentation it did not completely fulfill my expectations. He focussed on the one, although practical, solution and failed in putting another suggestion to work: data access encapsulation. As Andrej already pointed out, the reason why database refactoring (actually table refactoring) is so hard is that the table can be considered as the interface to your application. Hiding your tables with views or packages (what Oracle developer are doing for years using table api’s) could be a much better architecture.

Suggested Readings:

• http://www.agilemodeling.com/
• http://www.agiledata.org/
• http://www.databaserefactoring.com/