Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
Regarding an Agile Backlash

It's coming, as we all knew it would.

All in all, I think this is a bit of a shame. I'm not one to speak for others, but I'm sure the "originators" (for want of a better term) of agile processes like Scrum and XP are a little disconcerted to see their ideas turned into nothing more than fodder for technical books and recruitment checklists. (I could be horribly wrong about this. I know there are some people who think this was the entire point from the beginning, but I'm not that cynical yet).

The thing that turns so many people off is the steady evolution of the word "agile" into its sexier buzzword connotation of "Agile." These days, everything is fucking Agile this, Agile that. Let's not be distracted by the buzzword... Instead, try to remember the point of it all, and realize that these are just solutions to problems developers have had since the beginning of time.

One of the most stressful parts of being a developer has to be deployment. And especially re-deployment. We want our stuff to work, and we want the people who use our software to be happy with it. I used to absolutely dread uploading changes to an existing site because I was never confident I hadn't introduced new bugs into the code base. Having unit tests solved that for me, personally. I am now pretty sure my code hasn't regressed because of my adoption of this one practice. I happen to enjoy writing my tests first, before I write the code to make them pass, but that's a personal choice and it doesn't detract from the main purpose; being confident in my code. At the very least I'm less stressed out, which is a good thing.

I've worked places before where the developers didn't talk to one another. Stuff would get duplicated needlessly, and developers would go for days down paths that others had previously trodden. Having daily standup meetings where each developer goes over what they worked on yesterday, what they'll be working on today, and what's impeding there progress goes miles towards solving this. I'm not saying that this is the only solution, but it is a good, simple one.

Why does it suck so much when Uber-Developer A goes on holidays for a few weeks? Is it because they're the only one working on a project (or a sizable chunk thereof) and if anything goes wrong while they're gone everyone else is screwed? Why do some developers get so damned smart so fast, while others wallow in mediocrity alone in their offices for months? Is it because Mediocre-Developer B is useless? Try spreading the love around by pair-programming for a while. You don't have to be religious about it, but I've found that having at least some time together with another developer can go a long way towards alleviating the above problems.

How does our code get into a state whereby it becomes extremely hard to add new features? Why do we need 5 lines of comments to explain what a function does? It sure would be nice if we could just look at it for a few seconds to let the understanding sink in. By ruthlessly refactoring our code before it reaches this state we can fight the entropy. It also helps if our unit test suite can be run afterwards to make sure we didn't change the meaning of the code.

The bottom line, and the point I'm trying to make, is that the little bits and pieces that make up "Agile" processes are there to solve very real problems that we as developers have. In the end, it doesn't really matter how these problems are solved or what we call our processes. The purpose is to make our lives as developers easier. The whole point of being agile is to be able to react to change without fearing it.

Posted 10-05-2006 7:25 PM by Jeff Perrin
Filed under:



Billy McCafferty wrote re: Regarding an Agile Backlash
on 10-05-2006 10:07 PM

Here's Martin Fowler's take on the process of "agile" becoming mainstream:  He certainly shares some intrepidations of it becoming a bit too mainstream.

Joe Niland wrote re: Regarding an Agile Backlash
on 10-06-2006 5:12 AM

I've been thinking lately that it's more important to be agile (small 'a') than follow a process to the letter. Even in the largest organisations unexpected events crop up and it's easily possible that the chosen process cannot cope. Yegge was talking about the zealous application of XP, Scrum, ASD, Crystal, whatever and there are always people who take it too far.

I agree that it's a shame, but engineering processes will always evolve. I bet the first bridge-makers took their methods very seriously and also came under a lot of criticism about them. Now, thousands of years later, bridge building methods are stable and there are several agreed ways of doing it. So I think it's case of tearing the wall down and rebuilding it to get to a stage where we're sure we're doing things the right way, the first time.

Vikas Kerni wrote re: Regarding an Agile Backlash
on 10-09-2006 10:18 PM

Survic has argued very nicely why Agile is so divisive in .Net arena

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)