A good essay I finally got to last weekend is Eric Sink advocating code coverage. Code coverage is simply understanding how much of your code is executed within your application. For people like me who start off by sketching, revising, and honing their work, I'm sure an analysis of parts of dead code would be quite revealing.

But there were two other peripheral things about this essay that were very interesting to me. The first was a side comment Eric makes about how many lines of code he's written in the project:

"This library consists of 12,341 lines of algorithms, plus 5,819 lines of unit tests."
What's interesting about this to me is that Eric, who is a developer I completely respect, is writing about a line of code in unit tests for every couple of lines he is writing as actual project. Ever since I became the resident nag of unit tests, trying to lead by example, I have come to realize just how much discipline it takes to have serious test coverage. As time has passed I've been happy with our choice since it's been helping us release much steadier versions of our software. I've also learned a lot about how to test our code, which I'll hopefully find time to share on this blog later.

The second thing that is interesting to me is that Eric always seems to have a side project of some kind. As a CEO of what seems to be a successful ISV this is impressive since many people I know in positions like that tend to lose their technical skills as they accumulate the managerial/strategic ones.