Is Quality Negiotiable?

04 Dec 2007

A colleague pointed out an interesting article over on InfoQ aptly titled Is Quality Negotiable.

Obviously if you’ve ever written a line of code or used a piece of software this question has been implicitly or explicitly answered for you.

It’s fundamentally important that both individuals and organizational groups have a clear understanding of what quality means to them.  There’s no doubt in my mind that quality means very different things to different people but taken together that’s part of achieving a successful balance.  Debate is healthy and it’s important that you stay true to your core beliefs, be they writing unit tests or ensuring each release has suitable user documentation.  You can’t satisfy everyone but by talking through a problem or having concerns answered, a clear set of priorities and direction will be established.

As a developer, I believe quality is negotiable, it simply has to be.  Much to the same degree as a feature should be negotiable.  My personal philosophy on development would always be to release less features of a higher perceived quality then more features of slightly lesser quality (the old 100% of 80 or 80% of 100 problem) but I’ve come to understand that there’s a time and place for both.  Deadlines are a reality but there’s a balance that must be struck between tactical and strategic thinking. 

Focus too much on the tactical aspects of development and release planning and chances are you’ll be left with a pile of technical debt and a team of unhappy people jumping from project to project.  If you’re really good, there’s a good chance that you’ll have a few satisfied customers.  The early days of a start-up are often very tactical in nature, they have to be, but it takes a heroic effort across the board and is very difficult to maintainable in the long run. Tactical thinking is a reality and it’s important to make people aware of the costs associated with making short-term decisions.

Focus too much on strategic thinking and you’ll be hard pressed to ever build a realistic release plan let alone get features into customers hands that actually perform how they expect them to.  Truth be told, you’ll still accumulate technical debt.  Don’t get me wrong, I value strategic thinking and it’s a big part of what I do on a regular basis, but it should be relatable back to reality.

There’s an important balance to be struck and it goes beyond the code, the cost of doing business, or even the customer.  It’s been said many times before but quality is not magic nor is it something that can tacked on at the end of a project.  Further to that, the waterfalls froze a long time ago and it’s equally important in todays environments to remain flexible and open to change. Quality should be considered a characteristic of the process that went into creating the product and the act of managing that process is difficult at the best of times.