05 July 2008

Practice what I Preach - Code Reviews, TDD and RDoc

The first internal release (0.1) of my ongoing attempt to "practice what I preach" is complete. The program works well, has high coverage and acted as a catalyst for many of the quality tools and practices I've been discussing. Three things stuck out in my mind as I completed the release:

(1) Even on a one-man project, code reviews are beneficial. One night I spent hours in the debugger plus adding puts everywhere to complete the refactoring to accommodate changes. It was one of those late nights when I should have probably just walked away. What I realized when it was finished is that about 10 minutes of inspecting the code would have produced the same results as my hours of debugging. Perhaps all of you are smarter than me and wouldn't have this outcome, but give it a try sometime and see if inspection isn't faster. Or better yet, try an informal code review with a co-worker.

(2) I was shocked at how much completing the RDoc improved my code. When I started to write about something and it was complete hogwash, I could either try and explain why I had written complete hogwash or I could clean it up. It was about the same amount of work, so why not clean up the code? An example was the large increase in private methods. If they are private, I don't need to write docs on them. :-)

(3) I wrote most tests and competed the RDoc after the coding was complete. They came out well, so why not keep doing this? Because for my project, these activities are the point. So of course I will finish them. At my day job, the code is (mostly) the point. So while I took the time to do the "right thing" at home, at work I would've been under extreme pressure to move onto the next task. Even if you don't believe TDD will deliver higher quality code, it is worth doing just so testing (and doc) get done at all.

I am researching how to quantify "code rot". My management can quantify the gains of pushing code out the door half-baked if they can attract new customers as a result. But they don't have the foggiest idea what it has cost them in terms of their major asset - the code base which is essential to the viability of the business. If there were some code rot number(s) which were convertible into dollars, the number of jackass decisions may well decrease. Anyone have ideas on this?