Rallying to the “Agile” Cause

When it comes to the quasi-religious subject of development methods, I try to avoid sectarian violence. I like to think of programming languages, for example, in the same way that I think of wrenches: the all-purpose variety tend to do a wide range of jobs with only mediocre success — but when languages evolve under different pressures, they develop complementary strengths that we all later profit from recombining into more advanced hybrid tools.

At least as contentious is the topic of development method families, which I try to avoid calling “methodologies”–because “methodology” is, of course, the study of methods. “Paradigm” had potential as a better term, but it’s long since been wordjacked and left as a vandalized wreck by the side of the road. I favor environments and repositories that serve as method-neutral settings for capturing and representing developers’ goals and products, with Telelogic’s System Architect being a long-standing favorite.

It’s hard to find any good reason, though, to maintain my neutrality on the subject of agile development, as I’ve made clear during the past year both in print and in person. With this coming Monday marking the end of my time at eWEEK–more than 18 years after my first eWEEK byline–I therefore feel real disappointment that I never managed to find the bandwidth for a full review of the agile-oriented management tools from Rally Software Development.

I always had an excuse for putting something else ahead of Rally in my queue: As Robert Townsend said when he was running Avis, never do something in public that you can’t do consistently well. Reviewing a product that can’t be benchmarked, that pretty much by definition can’t be evaluated objectively–but can only be judged by the response that it produces from a development team, is a task that doesn’t lend itself to labs-based testing … unless you have a few dozen slave-labor graduate students that you can use as test subjects, and that’s not a resource that I keep on hand.

As I said, though, it’s a particular disappointment to me that I never found the time or the circumstances in which to give this product a full review in eWEEK–because the basic idea is right, the execution is polished, and the on-demand model makes good sense for this kind of thing. Developers have enough pain on their hands with configuring databases and setting up all manner of infrastructure as part of the task of actually delivering the applications that they’re paid to develop: I can’t imagine anything more perverse than to ask them to take time away from those somewhat productive tasks to set up a complex infrastructure for measuring and supporting their efforts. In practice, I find that such diversion of scarce resources just does not happen.

Rally’s product editions satisfy two key agile principles.

• Give motivated individuals the environment and the support they need
• The art of maximizing the amount of work not done is essential

Given the try-before-buy option that the company provides, the reasons for not trying it seem few and the potential benefits many. I wish I had time to say more, but this is clearly a case where your mileage is the only mileage that matters.