Archive for June, 2008

First Time Quality

June 22, 2008

I was listening to the stackoverflow podcast #10 in which Joel (of Joel On Software) stated that code should be written in two phases. The first phase in which you get the code to work and then a second phase in which you improve it. He also states that most of the time you never do phase 2 unless the code is important. I used to work this way and assumed (as Joel does) that this is the best way because I was so smart. I have since learned the importance of first time quality. I still haven’t turned this knowledge into action all the time as I still write code that embarrasses me 🙂

First time quality was something Deming wrote about in his 14 points. Particularly point 3:

“Cease dependence on inspection”. If variation is reduced, there is no need to inspect manufactured items for defects, because there won’t be any.

Obviously Deming isn’t writing about software, but the concept is similar. Testing software at the end is the same as inspecting manufactured parts. The quality of the code is already determined. This should not be news to anyone. Take this one step further, and when should you spend time making the quality better? The answer is obviously as soon as possible. Thus the better you are at writing good code from the beginning the better and faster you will be. For the rest of us (not a Done, and Get Things Smart person), this means we must get better at seeing poor quality and improving it as quickly as possible. To me the only way to do this effectively is if you write your code incrementally with quality checks along the way. I don’t know any method better than TDD to do this.

When doing TDD correctly I find that I can sense the internal quality of the code. I like the term Code Smell for lacking quality, but I also sense when things are going well. I sense that the software design is growing in such a way that new features are going to flow out of it. My productivity soars. This phase usually doesn’t last long as I inevitably do something stupid and cause the code to bloat with duplication. The beauty of TDD is that is allows these modes of hyper productivity while being a safety net for the times of hyper stupidity. I am not saying that TDD will cure all the ails of software development. As long as humans write code there will be ails. It is in our nature. I just know that true first time quality is such a boost to overall productivity that it saddens me that more people don’t do it. I think one of the reasons for this is that we have too many software developers that should not be doing software, but that is a topic for another post, another day.