Ambler the Agile

That Peter Robson chap is taking over my blog again. I do wish he'd get his own sorted out but, in the meantime, I'll let him squat here for a while. Over to you, Peter ...


In an earlier guest submission, I made reference to following up a rather critical review of the presentation by Scott Ambler at Collaborate 06 on agile database techniques.

Ambler included a paper to go with his presentation, which I have examined.

I stand by those original comments. In particular, I am shocked by this comment from Ambler: 'you do not need to do data modelling up front, its a waste of time, its the kiss of death'. A thoroughly irresponsible and outrageous assertion.

What was presented that day was nothing less than the recycling of a previously short-lived IT fashion, namely RAD, with a few added extras. Remember that? Rapid Application Development. I thought it odd that Ambler never made mention of the close similarity. Then perhaps not, as we never hear of it nowadays. A brief web search will confirm the similarity between the two approaches. There are differences too - check out Simon Evan's blog for a balanced comparison of the two approaches. Although he makes the case for a difference between the two, the development of agile from a RAD baseline is pretty clear. So generically, one can see them as being from the same origin.

Ambler's paper on Agile Database Techniques is insubstantial and misleading. Lets look at some of the things he says:

'The goal of the Agile Data method is to define strategies that enable IT professionals to work together effectively on the data aspects of software systems.' Really? So what's new - some of us have been doing this very thing for decades. (PS - Don't you think that word 'method' should be capitalised? )

'Enterprise issues. Development teams must consider and act appropriately regarding enterprise issues.' I cannot understand what the purpose of stating the obvious is in this context. As if any self-respecting developer would do anything other than this. One is left wondering if by making non-controversial and obvious statements, some credibility is being attached to the agile fluff by association.

'IT professionals must work together effectively, actively striving to overcome the challenges that make it difficult to do so.' Would anyone ever recommend IT staff to do other than work together effectively? Again, another padding statement of the obvious.

Here is a definition: 'An agile DBA is anyone who is actively involved with the creation and evolution of the data aspects of one or more applications.' Now some DBAs have been doing this for decades - does this mean that a) they were always agile anyway, and b) the agile DBA is in fact an old concept? The assertion is simply misleading, as though the cult of agility is trying to sequestrate long established practices and concepts as something unique to their way of seeing things.

'The critical new skills for agile DBAs enable them to work in an evolutionary manner.' Yes, working in an evolutionary manner is part of the critical skills set, but they owe NOTHING to the agile approach � they have been in place for years! Interestingly, despite referring to 'new skills', nowhere are they actually enunciated, other than under the vague umbrella of terms such as 'evolution' and 'iteration', terms which are part of the bedrock of sound data and systems analysis and modelling.

A diagram is presented. Thousand words etc. Well, in a technical diagram, if one is presenting a new approach to doing something, one would expect the symbology to be defined. There are arrows here, but nowhere are they actually defined in terms of their purpose and function. Yes, we can guess, but in a technical presentation, is that good enough? The very process of definition itself appears somewhat weak in this paper.

The interesting concept of the sandbox was introduced, but in such a way as to leave open the question of whether it is an agile feature or not. Of course it is not. It is defined - as '... a fully functioning environment in which a system may be built, tested, and/or run.' 'Environment'? Unless that word is defined, the overall definition is simply vague to the point of uselessness. Why does the word 'isolated' not feature? Why not discuss the relevance of VM to the sandbox approach?

This paper is shallow, uninformative, and completely overlooks if not denies the serious and careful work done by conscientious IT professionals over many years. I take great exception to the way the advocates of new fads spend time rubbishing all that has gone before. Whatever Ambler may say, or allow his reader to infer, the agile approach is most certainly not the IT panacea he would have us believe.

For another examination of agile software in general, look at Wikipedia. Read down, and you will find a discussion of those areas where agile software may not be so suitable :

- Large scale development efforts (greater than 20 developers)
- Distributed development efforts (non-co-located teams)
- Mission- and life-critical efforts

Have a look at what Niall Litchfield has to say on the subject - I absolutely agree with him.

Speaking personally, I would prefer not to fly in an aircraft in which the computer systems were built by a team of agile programmers. This is not so flippant as it may seem. Ed Yourdon, in a talk to a meeting of New York City SPIN (that's the Software Process Improvement Network - yes really!), [see blog by Francis Hwang] noted the increasing litigation directed at IT systems. One of the sure defences against litigation is complete documentation, and it is this area which would make a failed agile system highly vulnerable. The agile crowd don't dismiss documentation out of hand, but would reduce considerably the amount that is provided with a system.

It seems to me that Ambler has taken some of the core values of data methodologies, wrapped them up in a flashy covering, and presented them as something new, while castigating the very sources from which he cherry picks. This is to be regretted, particularly when the IT industry as a whole is struggling to establish truly professional standards. To paraphrase a comment from a friend while discussing this subject, he suggested that the presentation style had more in common with an agile used car salesman than a serious IT professional - a point of view on which I simply could not possibly comment ...