Friday, April 10, 2009

Software quality refers to a number of standards, from functionality (does it perform as expected) to performance (does it perform as QUICKLY as expected). When considering quality from the development perspective, the question "Does it work" is only the tip of the iceberg. For instance, in writing a base "Hello World" application, there are a number of ways to build, parse, and display a string to a monitor. However, if the code is difficult to read, difficult to repeat, or requires excessive configuration on the client computer, then even though it "works", it is not high quality. Examples of low-quality, working code abound, especially on

I have been researching Test Driven Development over the past few months, and I am finding that one a major predictor of final quality is continuous testing and refactoring as a project is in development. The theory behind test driven development (as defined at is that when you write a test before you begin coding, you will code only enough to pass the test.

The test-first methodology prevents the developer from adding code just because "I might need this feature later." According to the Extreme Programming wiki (, "You Aren't Going To Need It!"

In my own software, I have ignored these principles in the past to my own detriment. NDA's prevent me from going into specifics, but I have had to redesign whole sections of code because the original vision changed for a function by the time I was truly ready to implement it. Had I simply stubbed out the method, I could have come back later without impacting other classes and methods.

Further Reading:


  1. George Mauer said...
    Silly to be commenting on a post that's so old Joe, but I was looking through your blog and...well...I saw something I disagreed with on the internet and had to comment on it.

    While YAGNI is certainly a driving force for Test Driven Development, I disagree that it is the primary benefit. Yes, it's nice. So is the presence of an automated test suite that you can then turn into a deliverable. So is tests-as-documentation (though few .Net projects are disciplined enough to get much mileage out of this one). No, to me the primary benefit has been that you drive the design of your API by an actual usage of it. That is to say, rather than guessing how someone might use your code, you are actually going in there and using it.

    This makes an enormous difference. How many times have you tried to pick up someone else's code and wondered why the hell would they write such an awkward interaction story? It's everywhere, heck it's even all over the BCL. The fact is that unless you're using each and every one of the public methods that you expose you're likely setting others and yourself up for that bit of exasperation down the line. It can still happen with tests, but at least you've got a bit of reasoning on the table for your design decisions and that's really the best we can hope for for now.
    Joe said...

    Today, I would agree with you. At the time I wrote the original article for a class, I was coming off of a project where the development team tended towards the "Put everything in there, we can sort it out later" mindset. It was exhausting to say the least.

    You are absolutely right though, that YAGNI is but one of many benefits to using TDD. I think, perhaps, the benefits we rate most highly will have to do with the WTFs we've seen most recently... But that's just my two cents.

Post a Comment