Purposeful Software Development

The post is a quick response to mtelligent’s post on “The Cargo Cult of Test Driven Development”. Somebody referred me to this link and while reading, something struck a nerve (not a bad one… just one).

In the post it talks about how there is a feeling that Test-driven Development (TDD) is a form of Cargo Cult Programming. This can be interpreted to mean that the process of where you write tests in hopes of driving out the production code, has turned into another ritualistic software development process where the meaning of doing such actions is lost.

First off, this phenomena is something we all fall victim to now and again. What use to have real purpose has now become more habit than anything else and we forget why we even started. I have seen this happen first hand with TDD and will be the first to admit guilt. However, let me take you back to when it really meant something.

About 5 years ago I was placed on a project that was completely foreign to me… new team, new code, new technology, new everything. Prior to that I had worked with a team that practiced a modified form of Extreme Programming. In this version, there was no pair programming, there was no test-driven development. There were user stories, iterative development, refactoring, etc. With this new team I decided that I would give this TDD a try as I was hearing that a big piece of the agile benefit(s) were being missed by not unit testing.

I ended up doing a best attempt at TDD… actually writing tests before doing the development: i.e. making the test fail; implementing the code to make the test pass; ensuring the test passes. Holy crap! This took some serious brain tweakage. I mean, my mind was not supposed to work that way and it was some kind of miracle that I didn’t throw the whole idea out the window within the first week. However, I kept following it in hopes that I would start seeing the light. And then it finally happened! There was something absolutely amazing taking place… my code was slowly becoming more robust, testable (obviously), architecturally sound, etc.

This is something that I did not realize though while actually going through the pain. From what I could tell, I was just experiencing a new method of development that was preventing me from being truly effective. It took a while before enlightenment finally took place and I could see that what had happened was something quite magical. It’s kind of like that scene in The Karate Kid where Daniel LaRusso gets all pissed off at Mr. Miyagi because he felt that the only thing he’s been learning how to do is some old guys chores (paint the fence, wax that car, etc). This ain’t no Karate! It was at that moment in time that Mr. Miyagi reveled what was really happening. While performing these seemingly mundane chores, Daniel had learned Karate’s foundational body movements of self defense. He was on his way to becoming a wicked Karate Kid.

Sorry for the jaunt there… Anyway, from that day on I would tell whoever asked on what I felt about TDD and how I was convinced (and still am) it changed the way I did software development. However, time goes by and I we tend to slip into our old habits quite easily. Plus, at this point in time the TDD philosophy had permeated throughout the entire team and it was easy to see the bad habits that we all had picked up. Writing tests, just for the sake of writing tests was a common problem. Feeling things like, “Well Bob, I guess before we can start any real coding we need to write a test first.”

What really happened here is that we fell into the trap. We forgot why we started doing TDD in the first place. We forgot the purpose behind our actions. It’s not to mindlessly fill our test suite with a plethora of tests. It’s not to get 100% code coverage. It’s not to merely improve the quality of the product. All of these things cannot be accomplished through the sole act of TDD. These are usually things that we get for free as a result of reflecting on our code. Test-driven development is something that is chosen to be followed because it simply helps us write better software. While performing continuous analysis on the code our minds engage and we are able to operate at a level where we relentlessly make the code better.

With all that being said it seems a bit unfair to state that TDD as a whole is a form of Cargo Cult Programming. There are many flawed theory’s of testing out there. There always will be. However, if we as programmers can try and remember the purpose behind the methods we follow we can limit our chances of becoming part of the Cargo Cult.

-

If you enjoyed this post, it would be totally righteous if you subscribed to future posts via rss.