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.
You make a great point. Even re-design in a major is risky. I’m still hunting for stuff in Office 2007.
Mike
A long time ago in a galaxy far, far away, I was an electrical engineer.
One of the things they drummed into our heads then was that you needed to find mistakes as early as possible, as the cost went up ten-fold as you got closer to deployment. Namely, the cost of finding a defect in the field was 10X finding it in QA, which was 10X finding it in design validation, which was 10X ….
Now this is talking about hardware costs which might be argued to be a lot higher than software costs (not that I agree with that). Has anyone heard of such a cost estimate for software defects found in design, implementation, unit test, feature test, system test, final QA, and the field?
In addition, most people focus on the cost of implementing a fix, but I am not aware of anyone quantifying the total cost to a company in lost sales, company image, delayed purchases, etc.
Pipe up if you know better.
AllanC
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.
That sadly is indeed what some managers think. Its true to some extent at my company. So why is this? To me the answer is easy – because the metrics by which a project deliver are measured has too few dimensions. The end date dominates everything. There is no closure on such things as customer acceptance, defect rates, defect severities, etc. These take resources to measure AFTER the release, and by then, well, everyone is thinking about the next release.
The only way to stop this nonsense is to tie managerial bonuses and such to hard, measurable product quality.
Nuff said.
AllanC
well, whatever the situation is hardware defects involve hardware pieces that must be replaced, that’s obviously more expensive than “just” salary payment (which you have in both cases) I think they don’t expend time testing and designing because they don’t give a damn about what one has to do to “fix” those things, in fact they usually don’t even know! now on the difference between bug and design well, a change in desing might lead to a new version (even if it not a real one) and that’s a place for innovation, a well profitable marketing concept so I don’t think design errors are worse than real bugs, real bugs or code problems lead to malfunctioning where interfase problems lead to discomfort which again, can be used a way to show “support” and “feedback” from the company to it’s users.