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…)

What’s your worst fear as a software professional? My worst fear is changing jobs and joining a team that is in crisis. You’ve probably been part of a team, heard about a team or witnessed another team in your company deliver to one of those unrealistic schedules.  Often times, the project starts off right, but entropy slowly builds as changes are introduced to the schedule with the velocity of an open fire hydrant.  It doesn’t start that way: it builds with a crescendo.  It’s not a case of replacing the old water with new water; it’s a case of filling a pool that’s filled 98% of capacity while watching the water spill over the sides and drain into the streets.

It’s not the fear of working hard, long hours, or getting my hands dirty that concerns me - in fact I find crisis invigorating - it’s whether I’ll be empowered to make the changes required to right the ship that concerns me most.  There’s nothing like the feeling of dread when participating in an endeavor that controls your life because the leadership is making mistaken decisions that you believe are the root cause of your undesirable circumstances: the kind of decisions that dig the project into a deeper and deeper hole.

Well it happened to me when I started a new job as a Software Development Manager in 1999.  When I arrived at the office on that first Monday, I was the first one to arrive, and when the first veteran employee arrived, he greeted me with the traditional first hellos and said, “yeah, the guys will be strolling in late today, they just worked through the weekend.”  I knew instantly that things were going to be interesting, and I was not to be disappointed.

(more…)

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…)