≡ Menu

Being Agile is /not/ easy!

James Shore had a great blog entry about inflated claims, specifically now that agile is starting to cross the chasm into the mainstream.

What I find so interesting about Agile is that in order to be good at it, you have to do a lot of work both to stay disciplined and to become a better developer. In an agile team, your goal, your only goal, is to provide value to your customer. That means that if you take 10 months longer because you don’t keep up with the latest industry trends and write your own “Enterprise” Foo, you aren’t living up to your promise to deliver the most value for your customer’s dollars.

It doesn’t just stop there though. Today we had a deployment that in testing we discovered a bug. The bug was that a translator we use wasn’t changed when the corresponding code was, so when it pulled it out, it cast it to a String array instead of a List, causing a ClassCastException. The problem wasn’t in that we forgot to change it, it was that no test stopped us from moving it up. Why? Because the code was supposed to not change, and was supposed to be temporary, neither of which held true. So we as developers failed our customers because we didn’t do our job, fulfill our promise to write the best code we can, test-first, to deliver running, tested features.

Thankfully we *did* have good acceptance tests which caught the scenario, but it should never have made it that far. And that’s the trick with being Agile. If you slip, even for a second, it *will* bite you. You have to stay on guard constantly, and also constantly improve your code and yourself. Your customers, and your maintenance programmers, will thank you for it (meaning you can pat yourself on the back 3 months from now when you have to change that temporary, unchanging code without spending 2 hours chasing down a bug).