Last month was a busy month for me.  We deployed the first version (beta) of the product I have been working on over the last couple of months.  Meeting the deadline with all of the promised features (almost) was critical.  However, when you fix the time line and fix the feature set, then something else has got to give.  You guessed it, quality.

Quality is not just a concern over failures.  There is a level of quality in your successes as well.  So far, the feedback on the product has been very positive, so, at an initial glance it would seem that quality is quite good.  Humbly, I must admit that quality diminished in April.

How should quality be measured?  Is it simply in defects reported?  I think not.  Many times you will recognize the quality of the code when you start to add something new.  If you add something new and something mysteriously breaks, you have poor quality.  If hire someone new and it takes you an unreasonable amount of time to "explain" the code, then it is of bad quality.  I think the code that I wrote in April could quite easily fail in these scenarios.

How can you maintain high quality?  The simple answer is TDD.  Where did I go wrong last month?  Simply put, I got out of the TDD driver's seat.  How much of Red-Green-Refactor did I lose?  Pretty much all of it.  On occasion, I would write a test after writing the production code.  Also, I would refactor my code from time to time, but in the absence of tests (a major no-no).  I kept my "coverage" at an almost reasonable level ~85%.  But, considering it was hovering around 98% at the beginning of the month, I certainly ran off the road.

I could make excuses, like "I had a major deadline", or "the customer just wouldn't give on the requirements".  The fact of the matter is, I got lazy.  When considering a new feature, the first thing I should ask myself is, "How can I test this?"  I just wasn't disciplined.

I've been playing catch-up the last week or so by adding tests to boost coverage.  Perhaps I should have phrased that differently.  The point is not to boost coverage.  The point is to test what your product is supposed to do.  If you write the tests after writing the code, It is easy to fall into the trap of writing tests that exercise what you think the code is doing.  This is why it is so important to write the tests first.  Write a test based on your requirements, then make it pass.

Hopefully, I can get back on the road before I blow a tire and end up missing the next deadline.  I need to remember (and so should you), poor quality frequently hides from you in the short term only to throw you into a tail spin in the long term.

Tags: ,
posted on Tuesday, May 6, 2008 11:29 PM
Filed Under [ Agile Quality ]


No comments posted yet.

Post A Comment