Agile people still don’t get it
“Cute, but useless. Now let’s go back to work”.
Source: Otaku, Cedric’s Blog
Communication from the Agile camp needs to be better. In the past I’ve struggled pulling together the big agile picture. Though Jonathan Rasmusson does an excellent job in The Agile Samurai. It is hands-down the best book on Agile that I’ve ever read. Not because it contains bits that can’t be found elsewhere but because the Agile picture is pulled together very nicely providing an intellectual base camp for continued exploration. The samurai theme of the book is great because it reinforces the notion that if you’re talking about Agile then you’re not Agile. Just as if you’re talking about Zen Buddhism then you’re not talking about Zen Buddhism. I plan on writing a full review in the near future. But I digress.
In the past I tried Test Driven Development and I failed. I tried multiple times but now I think that I “get it.” I was so used to prototyping a bit here, building the project there, and prototyping over here some more, round and round. Then at some point I’d start sorting out the mess while trying to keep the fragile parts from breaking. I’m still not an expert and I still don’t always tackle every programming task with TDD but it makes me think about the problem that I’m working to solve instead of what I think the problem is.
Cedric criticized “Your code is your spec.” That’s one way to look at it but in doing so he misses the point. In this universe, tests [the code] can be the spec. Since an exponential function operates on data within a context the test examines its state. It’s a meta-statement about creating functional clean code. The Heisenberg Principle doesn’t apply here. He also advocates comments in code. I used to as well until I pored through enough legacy source and saw way too many comments that were lying to me. Sure, sometimes a short annotation is helpful for the next set of eyes but it has to be done judiciously. If comments executed and their state could be examined then it would be a whole different story. Last time I checked I couldn’t put a break-point on a comment.
Cedric also complained about TDD being used for toy ideas in presentations. He complained that he wanted comments along side code in order to understand what the code does but he wants an Agile practitioner to show him how to be agile on 500k line projects in 30 minutes or less. Funny how that works. Though In here a true gem is buried. Assuming a baseline of proficiency and understanding of TDD, If the devs do not know how to write a test for something then they probably don’t really understand the problem. In an industry where it’s not uncommon to one day be writing apps for the government and on another day writing medical software, being a software dev expert isn’t enough. Connecting with Subject Matter Experts and the customer is incredibly important. Through Agile I have been able to pose poignant and precise questions to SMEs and stakeholders. I feel that if I were not a student of Agile then asking such questions would have been far more difficult.
It also seems that Cedric conflates TDD with the Agile “cloud” of concepts. They’re not one and the same. TDD is an approach that can fall under the Agile umbrella. Agile is a guideline and emergent practices that can be snapped together like Legos to fit a particular setting or set of problems. Heck, I use Kanban and Lean along with principles of Agile. It’s about doing what works.
Tests are fantastic for continuous integration, especially when projects are 500,000+ lines of code. A couple of years ago a former coworker who is highly skilled showed me Cruise Control for .NET. He showed how he set it up and how it helped his team right a sinking project. I easily recognized the result but the inner workings seemed like an impenetrable monolith of arcaneness. I decided to rectify my lack of knowledge instead of complaining about it.
Cedric mentions smugness and infers dogma but then he goes on to say:
“Software is shipped with untested parts every day, and just because it’s not entirely tested doesn’t mean it’s bad software or that the untested parts are “useless”. Agilists just don’t understand the meaning of calculated risk. Early in the development cycle, it’s perfectly acceptable to go for a policy of “zero bugs” and “100% tests”. But as the deadline looms, these choices need to be reconsidered all the time and evaluated while keeping a close eye of the final goal. Very often, Agilists simply forget that their job is to produce software that satisfies customers, not software that meets some golden software engineering scale.”
That’s the problem! It’s part the whip-it-and-ship-it dogma that believes, “If we build it they will come.” It’s all too painfully obvious that software is shipped every day with untested parts. Somewhere in the neighborhood of 70% of IT/software projects crash. Could Agile have saved them? It depends on the group and their leadership. And of course doing something new isn’t as easy as old habits. Isn’t that obvious?
What he also fails to mention is that Agility means adjusting windage and elevation, making informed decisions as a team, so that the target can be hit with confidence. How can a close eye be truly kept on the final goal if it’s okay to take “calculated risks” on the fly? Are they really calculated? Who is making these decisions? Who is managing them? Embattled team members? Too often they’re made by people who have priorities that are divergent from the project’s stated design goals.
Here is an interesting indicator from the 4 year old article:
“So here is my advice to Agilists: get real now, or you will become irrelevant soon.”
Huh. They’re still here. My hunch is that they’ve been real all along.
What I see as one of the biggest benefits of Agile is that it provides a set of ideas and practices that are open for anyone to see and to test. If we endeavor to better our craft on our own then by what metric do we measure ourselves? And while doing so we may not notice Heisenberg tapping us on our shoulder.