Fixing bugs is not equivalent to fixing design.
I love cigars. I smoke about 1 per month as a treat. That may seem like nothing, but I really enjoy it. About 2/3 of the way through a good Rocky Patel, there is a moment of clarity. Greens become greener, blacks become richer and edges become sharper. A little Laphroaig doesn’t hurt either.
It is usually at this point that I come to some realization. Tonight that moment was defined by frustration regarding misconceptions of software design.
I evangelize design daily. I argue for the importance of good design, justifying the investment in time and resources to design and build smarter. But recently I was told a story about the iPhone that illustrates one of the sources of the cautiously skeptical expressions of many business executives that I meet with.
Hardware mistakes are expensive; software mistakes are (relatively) cheap!
According to one person, much more design and testing work went in to the hardware of the iPhone than the software, and the reason given was because it is much more expensive and unacceptable to ship defective hardware than it is to ship flaky, buggy software. (I cannot verify the accuracy of this claim and truly wish I had real data to support or deny this.)
At Dux2007 in Chicago, I attended a workshop where I asked the group why we don’t design software like we do hardware? Why don’t we spend more time in prototypes, mockups, etc. One of the attendees, a software designer… said “because it’s cheap to fix software problems – all you have to do is make a download available that resolves the bugs.”
That’s what so many executives are really thinking, aren’t they? Build it, test it, get it
out the door, and then ship fixes as necessary. Time to market, fix later.
And herein lies the mistake: fixing bugs is not equivalent to fixing design.
True, bugs in software can be fixed easier and cheaper than bugs in hardware. But we’re not talking about bugs–we’re talking about DESIGN. You can’t fix a design with a download! Design is the essence of the product, how the product interacts with users, the personality of the product, the metaphors, etc.
Attempting to fix design in an update results in confusion, retraining, potential loss of trust, etc. The changes are too significant. Therefore redesign is often delayed until the next major release of the product, resulting in additional costs, potential loss of customer loyalty and the opportunity to “lock them in”, etc.
So, yes, software bugs can be remedied easier than bugs in hardware. But design problems in software are no easier or cheaper to resolve than hardware design flaws, and therefore we (software designers, creators, builders) must adopt better processes, principles, and expertise towards designing better software products from the start.
