One of the more interesting quotes I've heard during the recent war coverage was something like

Military leadership is the art of making sure your men never have to fight a fair fight.

I think there's a similarity between this and successful software project management with an Agile approach. Often it seems that coding is the easy part of what I do as a developer. I have to squeeze coding in around requirements gathering, deployment, production support, maintaining multiple testing environments, and integrating with other teams. Somewhere in between all that, hopefully I'm building the software that my users want. Imagine if I never had to guess what my users wanted because they were sitting within earshot of me. Or if I didn't have to fight with lots of needless interruptions. It would be like not ever having to fight a fair fight.

When I had just started programming in school, at the very beginning, back before I even understood the importance of formatting code, I remember getting stuck on a programming task and asking for help from a guru. He looked at my code and said that he couldn't tell what it was doing because it wan't formatted. I sighed and said that I didn't mind the messy code, since of course formatting wouldn't change how it was evaluated. He insisted that we'd have an easier time of it if we formatted the code properly first. So we formatted the code, and sure enough the bug in my code popped right out. Secretly, I was a little disappointed. I felt cheated. "Oh, sure, well, now that he's cleaned it all up, no wonder he could fix it. I want to see him figure it out when it's messy! There's the trick!"

I've since learned my lesson, and I always format my code properly. The more I think about Agile practices, the more I think that doing the practices only gets you half of the benefit.You get the other half of the benefit from getting  *the rest* of the project into a state that lets you do them. I loooove unit tests, but I think that you get almost as much benefit out of having *testable* code as you do from actually having the tests. It seems that the first time somone sees a unit testing example they say, "Well, sure it works on that toy code, but my code is *far* more complex. It would never work on *my* code." And they're probably right. It probably wouldn't work on their code because they've probably mixed responsibilities all over the place. If they'd put in the work to get a clean design, their code would be easier to test, and the bugs would pop right out almost as much due to the cleaner design as to the redbars. The same goes for on-site customers. And short iterations. And continuous integration. You get almost as much out of *being able* to practice them as you do from actually practicing them. It's almost not fair.

Last Modified Monday, April 28, 2003