How not to advance software development practices

Jimmy Bogard, creator (I think, he’s listed as a Coordinator, but I think his role is much more than that) of AutoMapper, has a post up about Continuous Learning, where he states:

One of the more tiring arguments against ideas like Agile or Lean is the line of “gee, it used to be RUP, now Agile, now Lean.  Make up your mind!  I’ll come back in 2 years when it’s something else shiny you’ve latched onto.”  But that’s not an argument against ideas, it’s just an argument against change.


So we have two options – cling to what we know and understand for as long as there is a market for that expertise, or, continuously learn and grow.

Now, I (sort of) get where he is coming from.  If you’ve ever been in an environment where you try to advance current practices, and get a lot of riff-raff complaining about it, it can be incredibly frustrating.  “We don’t have time to do unit testing.”  Right, sure you don’t.  You have more than enough time sitting in debug mode trying to figure out why something doesn’t work, but taking preventative measures to allow you to avoid having to get to debug mode, no, that’s too time consuming.  Certainly.

However, the attitude he expresses is something I might call ‘The curse of the software craftsman.’ 

I’m not a grizzled veteran (okay, maybe I am) but I’m not a newbie.  I’ve been in professional IT since 1996 and done software development since 1998 or 2000 (depending on how you count it).  I’ve dealt with countless people who have been convinced of the ‘inherent greatness’ of all sorts of things, and what is notable is that the ‘ferventness’ of them seems to be equal, regardless of the actual greatness of what they’ve been in peddling.

Agile seems to breed people infected with the curse.  It isn’t the worst breeding ground (Linux beats it hands down), but it is pretty bad.  People who have learned Agile techniques seem to think that if you don’t immediately embrace Agile techniques, you are either against change or a Luddite or just stupid or something, and this is incredibly short-sighted.  It’s also just bad marketing.

I was lucky enough to be able to work with a guy who did Agile, and was otherwise incredibly intelligent, a much better developer than I am, who just did it.  I was able to pair program with him on one occasion, but was also able to observe him do TDD.  I learned to know when he had time to talk with me by observing if his NUnit test suite had a bunch of red tests (he already ‘broke the rules’ by writing multiple failing tests instead of doing them one at a time…all the more reason why I respected him) or if they were all green.  I wanted to learn what he was doing and why he was doing it, not because he was proclaiming his greatness, but because I could see it was helping him.

Setting up a false dichotomy of “either you agree with what I am doing or you are resistant to change” just doesn’t help.  This is especially true of Agile/Lean.  If you aren’t in an environment of the correct sort, you end up with fake Scrum or false Agile, where your daily standup involves everyone sitting down, etc.  You are better off not trying to do it at all (though maybe a Kanban board would help regardless).

Jimmy’s clearly a better developer than I am. I’ve never worked with him, but I can state that with confidence.  He’s probably also someone who, in a better moment, can be a positive advocate for change.

But his message of “you’re either continuously learning or you’re a moron” doesn’t really work. 

posted on Sunday, August 16, 2009 11:34 PM Print
# re: How not to advance software development practices
Jimmy Bogard
8/19/2009 7:25 AM
I realized after I posted that one that I didn't talk enough about companies where investing in IT (and therefore continuous improvement in tech) does not align with their business strategy. In those cases, why bother? Just like in non-complex domains, why not just do forms-over-data?

I didn't mean to disparage those that are fine with the status quo, that's certainly their choice. But, too often these people are put into architect positions, where they have 10 years of experience of the same year repeated 10 times.

I have also seen billion-dollar companies stagnate because their culture was not one of continuous improvement, from their business strategies to their flagship products. It's very tough to be the guy championing change, if the environment does not accept and embrace it.

Post Comment

Title *
Name *
Comment *  
Please add 3 and 2 and type the answer here: