Tools As Agile Catalyst
test driven development, software development
Brian Marrick looks back on 5 years since the Agile Manifesto:
I think it no coincidence that so many of the Agile Manifesto authors had past experience with Smalltalk (or, in my case, Lisp). That kind of background makes it easier to think of software as something you could readily change. I don’t think Agile would have taken off without semi-flexible languages like Java and the fast machines to run them.
Moreoever, each new tool—JUnit, Cruise Control, refactoring IDEs, FIT—makes it easier for more people to go the Agile route. Without them, Agile would be a niche approach available only to the ridiculously determined.
I’ve heard this idea before that Agile methodologies wouldn’t really work that well until we had IDEs that could easily allow refactoring and languages like Java, Ruby, C#, and Python. I find the idea has a lot of merit. Part of the appeal of Agile is the tools make refactoring a whole lot easier than it used to be.
The one thing about tools that still makes me twinge is when someone explains how you can just click, drag, drop a snippet here, step through the wizard, and bang you generate all your code. This is where the tool is supposedly doing all your work for you. Since this often makes TDD just about impossible these sorts of tools feel really flakey. They often generate just really awful code as well. The final nail in the coffin is you can only ever look at the code effectively or change it by firing up the tool. Those sorts of tools seem really anti-Agile, much like Microsoft Project or the Rational Suite.
Technorati Tags:
software development, test driven development
Ed Gibbs @ January 31, 2006
“Part of the appeal of Agile is the tools make refactoring a whole lot easier than it used to be.”
My experience in the past six months has shown the exact opposite. Yes, tools in theory would make refactoring easier. Eclipse vs grep.
It’s simple logic, but it doesn’t match reality. The reality is that tool economy thrives on complexity and wizardry. The combination leads to code that’s easy to refactor, if by refactor you mean changing class and method names. Eclipse is a marvel for renaming and relocating.
With Java I often rely — no — depend on tooling and wizardry. The resulting code is best left alone, and what can’t easily be managed can’t easily be tested. That which can’t be statically checked is generally not well covered.
With Ruby I have zero tooling support, but less code means less change at each iteration. And the restriction on simplicity means a ratio of around 1:1 code to test cases. I have much more confidence that the code will survive refactoring without breaking.
I still think it’s counter intuitive, but I can see why empirically it works out that way.
With POJO I’ve never had much of an issue with testing coverage. And the refactoring tools and the like work great. I tend to use IntelliJ which is very light on the wizard stuff as well.
I have had first hand experience however with dealing with tool driven code, aka generated code. This is always a royal pain to get into a test harness and often not worth it because every time you bring things up in the tool again it regenerates all the underlying code. So my first rule with any tool is how do we test it? Unfortunately we adopted things like JSF before we had a good answer to that one, but we’ve been able to work around it so far.
I’m in the process of doing a dive into Ruby in my freetime, hopefully I’ll get back to the Pickaxe book tonight. I’m writing lots of unit tests along the way to check my understanding and generally really enjoying being back to a very simple environment. I totally understand the appeal of a very well defined language with one major web framework and the lack of beasts like EJB, JBI, BPEL, SDO, JDO, JSF, etc.
That said the one think I miss in Ruby so far is a really nice refactoring IDE, but I’m figuring I’ll miss that less as I get deeper into it. I’m using the RDT eclipse plugin for now.