Monthly Archives: August 2010

Re: Agile people still don’t get it

I read a rather old post that was recently brought to my attention by DZone.  Cedric’s title is provocative: “Agile people still don’t get it” and he also concludes with a provocative statement:

So here is my advice to Agilists:  get real now, or you will become irrelevant soon.

Now, I’m rather a fan of Agile in general and lately, Lean Software Development in particular, so I read it with interest.  The main criticism of the article is that he clearly had a noob for a TDD trainer and he shouldn’t generalize too much to the rest of the world from that.  Take a look at this leap:

Fundamentally, I am disturbed by the Agilists’ dishonesty when it comes to presenting their arguments.  They offer you all these nice ideas such as Test-Driven Development and Pair Programming but they never — ever — disclose the risks and the downsides.  To them, Agility is a silver bullet that is applicable in all cases with no compromises.

I don’t know if I would apply the label “Agilist” to myself, but I think I’m who he’s talking about and I was surprised to learn that I never – ever – disclose the risks and downsides.  In fact, in my particular conception of Agile, it is applicable in almost all cases because it allows lots of compromise.  Let’s not confuse the principles with the practices.  Number one in the Agile Manifesto (and I’ll admit I see a lot of people act like this isn’t the case) is “…we have come to value individuals and interactions over processes and tools.”  So I’m allowed to be an “Agilist” and say, yeah, for you TDD (a practice) might not work because you have so much legacy code, or you have a high tolerance for bugs (I would examine that particular claim closely) or whatever.

There are two main sentiments with which I agree with the author.  First, I don’t like orthodoxy and he doesn’t, either (at least not Agile Orthodoxies).  The second is that Agile is no substitute for discipline – but unfortunately, neither is any other methodology.  You think a command-in-control methodology like Waterfall (which no 0ne really uses 100% either) makes people disciplined?

Take the example of documentation.  There was a theme in the article that Agilists disdain for documentation made it difficult to understand code.  Now, I’ve been a professional developer for 16 years and I have (I am pausing before I write this to see if I can think of any examples… nope) never been confused by code that was made clear by external documentation.  Comments, sure, but UML? Design spec? Often those documents lie anyway.  Either they were written lazily by someone who was just checking a box, or they were written earnestly once a long time ago and never kept up to date.  I’m not saying a high level architecture document isn’t useful, but if you’re looking at some spaghetti code and you think to yourself, “if only I had the design spec I could untangle this” then I would say that you need to get real.

Must Reads for a Software Developer

JavaLobby has a post up regarding Must Reads for Software Developers.  Although the title doesn’t mention Java, it’s a pretty Java-laden list.  (It’s JavaLobby after all).  Just my two cents:

Refactoring (Martin Fowler) and Design Patterns (GoF) are interesting because many of the things talked about are so ubiquitous now as to be almost invisible.  The Observer Pattern? That’s just pretty much how events work these days (but not at the time it was written).  Rename a variable? That’s so easy and cheap in most IDE’s that you forget that there’s any trick to it at all.  That being said, I don’t think they are only interesting as historical documents.  Just the intro to Design Patterns changed my whole way of thinking about OO design.  And the Refactoring book still has plenty that isn’t implemented in some IDE’s as well as vital discussion of the principles proper motivations behind refactoring in the first place.

One that I would add to the list is Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin. If you want some deliberate practice to make you a better professional, you can’t go wrong with this book.

No Java required for any of those three (although I would say that Refactoring would be pretty different in dynamic languages like Javascript).