I have so many things to blog about today, I don’t know where to start.  And, I really don’t want to spend all day blogging.  So, here’s one thing on the list that really stood out, almost as much as the cat poop recycler from the previous post.

James Shore, an Agile development consultant and author, has a post with the attention-grabbing title The Decline and Fall of Agile.  He laments the number of teams out there who have adopted “agile practices” and ended up with an unmaintainable system.  He fears, as one who makes his living off Agile might, that this will be seen as a failure of Agile methods, Scrum in particular.  Really, he thinks the real problem is that teams are adopting the “fun” parts of Agile, and leaving out the parts that really make it work:

It’s human nature to only do the stuff that’s familiar and fun, and that’s what has happened with Agile. People look at agile methods as a chinese menu of practices, choose the few that look cool, and ditch the rest. Unfortunately, the parts they leave out are the parts that make Agile work. 

The article’s comments are great, too.  There lots of good insight there.  For example:

People want a software, a CD-ROM to install something, a tool, a template, and they don’t understand that Agile is not about a process or a tool.  
 
It’s a cultural change.  
 
Different mindset.

The discussion reminds me of my post, The Process is Your God Now, where I talk about the need to treat the less fun aspects of programming like rituals.  For example, treat checking code into source control like saving in a video game:

Now, back to my game, what if I come to a fork in the road.  I can go left through the ominous looking sewer, or I can go right through the abandoned city.  Well at this point I’ll go and save my game with some sort of name like “Taking the sewer”.  That way I can continue playing, quick-saving as I go, but I can always get back to that fork if it turns out I made a mistake

I highly recommend this podcast from IT Conversations.  It’s by Ken Beck, “the father of Extreme Programming and JUnit”, and one of the earliest supporters of Test Driven Development.  Ken was asked to share stories with the audience, and gave some great advice in the process.

One part (about 58 minutes in) really stood out to me, as it ties into my post on developers getting “religion”:

That’s why I like that word “responsible”. “What is the responsible thing to do in this moment?” That is a wonderful, wonderful question to ask. “How would I do this if this was my money?” Boy, that’ll focus the mind on documentation.

Listen to Test Driven Development, Patterns and Extreme Programming at IT Conversations.

I did a little work for a client while watching a movie last night. I added transparency to a wrapper around the GD library, and I started thinking about the code I was writing.When I saw the first transparent PNG from this code, I was so proud. I wanted to wake Amy up and show it to her.

My gut reaction, like that of many programmers, is to look at the code I produce as my child. I gave birth to it, and nurtured it. I watched proudly as it took its first steps, and even watched it venture out into the real world (this library plays a big part in that site that got written up). But what if this library isn’t as great as it could be?

My gut says I shouldn’t let some stranger touch the code. They’ll only mess it up, and make it work differently because they don’t think like me. Worse, if they make something better, it reflects poorly on me, doesn’t it?

No, it doesn’t, because my code is not my child. If I am going to look at it as a child, it’s the whole team’s child. You see, one principle of agile development is Collective Code Ownership, and I strongly agree with it. I may have written the first versions of this library, but the rest of the team has to use it. And the real measure of the its success is how productive it makes them, how quickly we’re able to produce quality web sites. I can’t make them depend on me for their success. That’s not fair to them, and puts extra responsibility on me.

So, if developers are going to carry on with this “my code is my child” metaphor, we need to change what that means. It can’t mean “keep your dirty mitts off my baby”.

My code is my child. Give it hell. Make it stand up on its own. Make it succeed or fail, and help it improve where it lacks. Like a parent at graduation, I want to see it succeed.