Quality vs. Quantity.

Earlier, I looked at how quality takes time.  Intelligence and other attributes are key ingredients that stop there being any simple formulaic way of determining quality simply by the time spent producing work.  It stands to reason that the longer you take to produce one unit of work, the less units of work you will be able to achieve in a given time frame.  Quality and quantity fight against each other every day.

It is probably a result of our social conditioning that most people strive to achieve quality in preference to quantity.  Throughout our schooling, accuracy and neatness are rewarded with good marks and cooing comments from proud parents.   As anyone who has read “Zen and the art of motorcycle maintenance” could tell you, defining quality is a difficult thing to do.  As a result, different programmers tend to have different ideas on when code has reached the status of “good code”.  Revisiting this code six months later can be quite a revelation!  More often than not, the opinion on whether the code was “good quality” or not has changed somewhat from the time of its original inception.

Software is a peculiar thing though.  At this early age of the computer industry, it doesn’t reward quality work – it rewards quantity work. Guy Kawasaki’s (in)famous “Don’t worry, be crappy” quote makes a lot of sense, even if the idea has serious limitations.  Earlier I suggested that quality and quantity compete with each other.  This is true – but unless you complete your body of work, the quality may as well be rubbish as no one apart from you will ever see it.

I feel dirty writing this post.  I strive to make my work “high quality”.  Sometimes it even passes the six month rule!  (I hate to say it, but sometimes it doesn’t…)  I always strive to improve my standard of coding.  Coding is only one aspect of a programmer’s  job.  Another aspect revolves around written and verbal communications.  In my mind, communication is probably the most important aspect of most (if not all) jobs.  This is certainly true of computer programming.

Written communications also deal with the quality versus quantity debate.  Blogging is my way of trying to improve in this area.  I am generally happy with the quality of my written work but, it comes at the expense of quantity…  Blogging is my way of “letting go” of the fear of producing sub-standard work.  I don’t think I have made a post yet where I have been 100% happy with the material I have written.  I always wanted more time to correct details, fine-tune sentences, find more references to support my views.  Still, one has to start somewhere!