You Want IT When?

For about 10 months I’ve had the world map displayed on the top left sidebar of this web site. It’s a really cool free widget created by amung.us. Whenever a visitor visits the web site, it posts a marker on the world map identifying the location of each visitor.  Recently, the markers on the map have been resetting everyday.   Since I like the cumulative record of visitors on the map, I contacted the company and asked why they made the change, and here is their response:

We experienced some technical difficulties at one of our data centers which resulted in some users missing stats data. We are attempting to recover any lost data, and restore the service to full working capacity.

Thank you for bearing with us during this time.

Christopher C. Shannon

whos.amung.us

Christopher responded quite rapidly, and I appreciated his frank response.  However, I grew impatient waiting for a fix, and I’ve been thinking about upgrading to feedjit.com for a while now. I hesitated because I didn’t want to lose all the data that has accumulated since I’ve been using maps.amung.us.  While I was drawn to feedjit.com’s widget because I like the map better, it wasn’t enough to make me switch even though maps.amung.us hadn’t made a single improvement since I began using the widget ten months ago.  However with this defect, there was nothing to lose by giving feedjit.com’s widget a try, and so I did. 

The web changes everything.  Now that so much software is offered for free, the barrier for switching vendors based on price is gone.  Consequently, high quality is even more important when the barrier to switching vendors is nearly zero.  Quality and useful features on the first delivery are a competitive advantage, and they are often more important to consumers than new/enhanced features delivered frequently.  Incremental, frequent enhancements to satisfied customers is simply not required, but if you get your quality wrong or deliver the wrong features, you will lose customers — even formerly satisfied customers.

If you liked this essay, you may also like the following related posts.

• Agile Content is the Goal
• Does Agile Solve the Right Problem?
• Burnt Toast

“I’d rather drive a Pinto that works every day than a Lexus that always breaks down,” said an unsatisfied customer of a company that delivered a product plagued with quality problems.  For him leading edge was less important than quality, or to put in other way, leading edge features that don’t work is like not having the features in the first place.  That’s true for most customers. 

It appears that the software development community believes that customers have a high tolerance for product defects.  How else can you explain the low quality that we often experience in the software products that we purchase?   I’ve often written about my experience with video editing software where it was difficult to find a product that could compile an edited sequence successfully.  Essentially, many of the video editing products at the time could not reliably complete the primary function for which people purchased them: compile sequences to a single AVI file.

(more…)

Early in my career I had the good fortune to work under a management team that valued producing high quality applications - ones that rarely, if ever, crash under continual load.   The director of the department believed, not only in words but in action, that a defect discovered in the field is significantly more costly to fix than one discovered in development.  We lived by that rule, and we all believed in it.  

For this product, we did not have a sustaining engineering team to fix and deliver patches to the field because it was simply not needed. Over the course of the seven years of working on this team through multiple product deliveries, I recall only two or three issues from the field that required an engineering fix.   Now think of all the features you could deliver by investing the money saved in a sustaining engineering team into new feature development. That’s what we did.

I’d like to describe the six practices required to produce and release stable applications.  The level of stability that you achieve in your products will correlate to the degree to which you commit to these practices.  The strategy by itself isn’t enough to achieve great results.  Great results require discipline, persistence, and a strong will, and most importantly, it requires a leader and a team that values quality above all other criteria.

(more…)

You’ve probably heard someone say it, or you may even say it yourself:  “You design quality into a product; you don’t test quality into a product.”  The last time when I heard those words uttered, I had to restrain myself from reacting.  What did this person mean by that?   The product was in trouble.  It released late and with low quality.  Customers were rolled back to the former version, and now the product marketing team fears that if things aren’t corrected soon they will lose market share.

(more…)

When re-reading the essay “Nine Steps to Defect-Free Software,”  I stumbled upon a gem of a quote by the author.

In retrospect, virtually every decision against trying for defect-free and in favor of short schedule time was wrong and resulted in longer schedules, more bugs, more support, higher costs and smaller profits! by Terry Colligan, president of Tenberry Software, Inc.

It has been my experience that shortchanging quality has always had a negative impact to the team and the organization that was never worth the trade-off.   How about you?  Has this been your experience?  If so, why do teams and management persist in repeating this mistake? He is also saying that shorter schedules don’t improve project success.  In fact, they contribute to project failures.  That is contrary to the Agile tenent of short release cycles.  What do you think?  I’d love to hear your thoughts.

Did you ever read one of those articles where the writer had instant credibility?  I recently stumbled upon one when I was looking to get my web site indexed on dmoz.org.  The article is titled “Nine Steps to Delivering Defect-Free Software” by Terence M. Colligan.  When I read the article I knew he isn’t just writing about somebody else’s experience because it mirrored my own experiences when I was writing software myself.  In the article he identifies nine traits contributing to defect free code.

(more…)

Have you ever been so frustrated with a piece of software that you wanted to scream?  I’m sure it’s happened to you.  You’ve just completed a part of your project that you’ve worked so hard to get right and then – poof — magically the application goes away and you just lost all of your important changes. It happened to me when I started to get involved in video editing. It was difficult to find an application that I could successfully complete an entire project.  I evaluated many of them before I settled on Adobe Premiere, and even that was buggy; it happened to be the best of the field of video editing applications.

(more…)