Impressions of an Agile Process
Tomorrow is the last day of my first scrum sprint, and after a good deal of initial distaste, I wonder if I'm not warming up to the idea of agile development. My first impressions of agile are that as a methodology, it places too little faith in the experience and architectural capability of developers. Indeed, it seemed to me to force developers to abandon their natural instincts for abstraction in favor of a 'get it done now' mentality that actually encouraged hackery and sloppy development. Then I was given this paper by Kent Fowler:
http://www.martinfowler.com/articles/designDead.html
Not that Kent Fowler gave me the paper, but that he wrote the paper. Anyway, it's well worth the read, and has given me a renewed hope that agile just might have something to offer the struggle to produce better software. I remain skeptical of some of the more extreme aspects of extreme programming, but this paper does a good job of explaining some of the why behind the agile approach instead of the relentless drumbeat of the how.
For me, the paper highlighted two extremely important points: 1) Agile does not dispense with design, it simply takes a different approach to it, and 2) It is a central tenet of agile to write code once, and only once.
With respect to the first point, the paper describes two broad approaches to design, Planned, and Evolutionary, and argues that neither approach works in and of itself. Furthermore, that planned design is doomed to failure, and that only the evolutionary approach can be made to work, but only if the disciplines of agile development are applied, such as continuous integration, testing, and (most importantly for me) refactoring.
Now it seems to me that refactoring is just another word for abstraction, which is something developers have always done (at least the good ones, in my experience). After all, development is really about the pursuit of laziness, even to the point of being ambitious about it. At the end of the day, we want to write as little code as possible to achieve the most functionality. And it seems to me that this is the part of agile that I had misunderstood. In order to make the evolutionary approach to design work, the code base must be constantly refactored (i.e. abstracted). There are probably lots of XPerts out there gnashing their teeth at the fact that I have equated refactoring and abstraction, but that's how I see it currently (I reserve the right to change my mind).
And therein lies the rub. If the discipline of refactoring is left out of XP, what you end up with is the worst case scenario of evolutionary design, a lavaflow of spaghetti and any other metaphor you can think of to describe horrific code. And that was probably my biggest problem with agile, in that I saw it as encouraging this kind of hackery.
Which brings me to the second point, 'Once and only once.' The takeaway being that agile does not dispense with design, it simply argues that the best way to achieve a good design is to develop only what you know (and really know you know) and leave the rest out until you actually have a case for it. In this light, it seems to me that developers have already been doing this for a long time. Chris Date calls it the Principle of Cautious Design, namely that unless you know exactly what the requirements are, you can't design a proper solution and so you're better off leaving it out.
In short, I highly recommend reading the above paper to anyone who is skeptical of agile development. While I'm not completely sold yet, I'm at least convinced there is something to it.
Bryn Rhodes
Database Consulting Group LLC