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 http://thedailywtf.com/.

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 http://www.agiledata.org/essays/tdd.html) 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 (http://c2.com/cgi/wiki?YouArentGonnaNeedIt), “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:

http://c2.com/cgi/wiki?YouArentGonnaNeedIt

http://thedailywtf.com/

http://www.agiledata.org/essays/tdd.html

http://www.ibm.com/developerworks/java/library/j-eaed2/index.html

http://msdn.microsoft.com/en-us/magazine/cc163982.aspx