11 August 2009

Quality's Okay, But Who's Paying the Freight?

One of my favorite truisms used to be
good software ain't cheap and cheap software ain't good
It's a parallel phrase that seems to ring true. I appreciate a catchy chiasmus as much as anyone, but now this aphorism seems like a marble in a rock stack.

Lets face it, sometimes cheap software is good. How often do we balance expeditiousness with quality?

Demand for our software services is throttled by the people who buy the products. It is almost always our charge to strike a balance between cost and quality constraints. Dogmatic pursuit of quality might be persceived as gold-plating. The economic reality is
selling software is a prerequisite for being paid to build software
Two observations about expeditiousness and software quality are:
  1. Often teams are faced with a simple choice: more features or higher quality (e.g., refactoring, paying down technical debt, bug fixes).

  2. Often that choice of more features or higher quality is determined by whether your product is a greenfield start-up or you’re supporting an established, public-facing product.
Start-up Product

In the context of a greenfield project or a start-up product, I have been introduced to the concept of Minimum Viable Product or MVP.

In Minimum Viable Product: a guide, Eric Ries explains that an MVP is made to elicit feedback. He defines it as
a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort ~Eric Ries
Kent Beck discusses Eric's approach in Approching a Minimum Viable Product where he uses MVP to address critical product assumptions, and to illuminate the unknowns, for his new product Tattlebird.

Presumably some degree of quality is sacrificed to get answers. The value of expeditious answers supercedes quality issues like user experience or reskinning a user interface.

Established Product

On the established, public-facing product front, Anna Forss wrote about establishing the notion of business value for bug fixes to the sales organization of her customer (cf. what value does bug fixing have for sales?).

Anna poses Fred Reichheld's The Ultimate Question
How likely is it that you would recommend product X to a friend or a colleague?
In the context of an established, public-facing product, she suggests that
...bugs create more detractors than features create promoters ~Anna Forss
In this content,
Value = Promoters - Detracters
Higher quality (user experience improvements and bug fixes) provides real value; in some cases more than new features. Sometimes error-free operation and usuability trumps new features.

If there's no need to walk the goldfish, use a fishbowl. ~Bobtuse

Given the context (startup or established), I understand the need to balance expedience and quality. As long we are focused on who's paying the freight and that their goals jibe with our mode of operation.