This post originated from an RSS feed registered with Agile Buzz by XP Cincinnati. Original Post: Understand your Code! Feed Title: XP Cincinnati Feed URL: http://xpcincinnati.org/xml/rss/feed.xml Feed Description: XP Cincinnati is the website of the XP Cincinnati eXtreme Programming Users Group. Latest Agile Buzz Posts Latest Agile Buzz Posts by XP Cincinnati Latest Posts From XP Cincinnati

I’ve been corresponding lately with a colleague who’s trying to bring agile practices to his development team. He’s been having trouble convincing them to practice TDD (Test-Driven Development). One particular complaint that he had (in regard to functional tests that were failing at the time) was:

Oh and also [I hear] the argument that the test is failing but the application code is fine so therefore the test code doesn’t need to be fixed. sigh

I replied to him via email, but I’ll share that reply here for your pleasure:

Try replying [to the above argument] with this:

OK, so the application is working even though your test is failing. The point isn’t really whether the application works now—it’s about how well you’ll be able to maintain the application in the future. For the system you guys are working on, maintainability should be one of your primary non-functional requirements, because this isn’t something you’re going to hand off to a client and never have to see again. The idea is that you want to be maintaining this system for a long time to come, because that means your company is still making money from it (and that your team still has a job).

Failing tests in combination with “working” application code indicate that your team doesn’t understand why the application works the way it does. You’re basically “programming by accident.” (Also called “programming by co-incidence”, see The Pragmatic Programmer, by Andrew Hunt & David Thomas) The point of TDD isn’t just to ensure that your code works; even more so, the point is to ensure that you understand why your code works.

Would you trust an airplane that was built by people who simply followed directions out of a manual without understanding the principles of aerodynamics and jet propulsion?

Would you want a company to build a nuclear power plant near your town if the engineers didn’t fully grasp the concepts of nuclear physics or know why the reactor works the way it does (“Hey, our other plant hasn’t had a meltdown yet.”)?

Extreme examples, sure—but as a customer, I know I wouldn’t want to invest a lot of money in a software system that was put together without the developers knowing why it worked. (Especially if I find out a few months down the road that it’s been silently corrupting my data all along—it’s happened before.)

Programming without tests, and without a thorough understanding of your code is like shooting a gun at a target with a blindfold on. If you start out pointed in the right direction, you’ll probably hit the target most of the time. But if someone bumps your arm, who’s gonna clean up the dead bodies?