Delivering Quality Software

Coworkers who know me well will tell you that I am passionate about delivering quality software.  I have a mild obsession with unit tests, code coverage, complexity statistics, FxCop analyses, and the like.  I get a geeky satisfaction when I pop open a code coverage report during a code review and see coverage stats up in the 90s.  And few things are more professionally satisfying to me as a developer than a good code review session where we boil a seemingly complex ball of logic down into a few simple lines.  Ah, great success!

Now, I’ll admit that I’m a rare breed.  I write lists for everything, I love my Quicken account registers, and I spend an inordinate amount of brain cycles thinking about efficiency (my car-packing skills are the stuff of legend!!).  But, while these traits may explain my attention to detail, they don’t explain why I care.

Delivering quality software allows me to innovate faster and deliver more than others who don’t monitor quality. 

As a creator/architect/designer, I can try new ideas with the confidence of knowing that bugs will surface immediately.  If my code breaks something, automated unit tests will fire error notifications and I will know about the problems – fast.  These messages give me the information to address problems quickly before additional logic complicates the fix… and they also give my team the guilty pleasure of asking me to don an obligatory “you broke the build” pink  cowboy hat.  (We geeks love our build rituals.)  As a result, I can try new ideas without investing hours or days in manual regression tests for each trivial change.  Effective unit tests take time to write, but they pay me back with dividends.

Since I can innovate faster, I can deliver more.  Naysayers and change-phobes no longer can persuade me that it will “take too much time to make a change.”  I can refactor with courage and deliver better software.

Plus, it’s fun…