- Now Where?
- An Analogy with Electronics
- No Crisis, It's All to Do with People
- A Split In the Ranks
- Fashion versus Progress
- So, Where Is It Going?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
No Crisis, It's All to Do with People
Interestingly, neither chip design nor mainstream electronics development is highly proceduralised or process-heavy. Yet nobody talks about a "crisis" in electronics as they do with software—because in general, there isn't one. So, how is it done?
Chip design is highly skilled and often very creative, and yet it is done under intense pressure to get products to market ahead of the competition. Most chips are produced on time and to high quality levels, but this is not achieved by relying on formalized processes (because you can't formalize design). It's achieved by hiring highly skilled people, forming them into supportive teams, and providing them with powerful simulation tools so that the design can be tested before it is realized.
Where formality appears is in the documentation and testing, in which the specification of the chip's behavior is expected to be complete, and the testing is expected to guarantee conformance to it.
In mainstream electronics development, there is less stringency, less simulation, and still plenty of suck-it-and-see debugging, but because the building-block components are powerful and reliable, most of the mystery and hair-pulling has gone. The devil is in the detail, and the detail has been taken out of most circuits and packaged into the chips.
Customer Expectations
Chips weren't always produced to stringent levels of quality. In the 1970s, some chips were as badly documented and as unreliable as many software components are today.
Of course, there are difficulties in the analogy with electronics because there is no similar mass-production of software designs, but the following short anecdote might illustrate how quality expectations changed. In the 1980s, people accepted that some electronics components they bought would be faulty, and as a result everyone who used them had goods-in testing to check them. Then a quality revolution began, starting in Japan. My anecdote concerns a conversation that happened between an American buyer who was trying to purchase a million chips from a Japanese supplier. The buyer was trying to explain that he was willing to accept a failure rate of up to 0.4% in the chips, but the supplier just couldn't understand what he meant. Eventually, the Japanese supplier asked, "These 4000 dud chips—you want them packaged in with the good ones, or separate?"
The culture of zero-defects had arrived, and today nobody does goods-in testing of electronic components.
How different it is in software. If you buy a software component, you will often get minimal documentation, and you would be quite surprised if there were no bugs, especially in a new product—not because software can't be thoroughly tested, but because you expect that it won't be. Instead, you evaluate the product to see if it works—the software equivalent of goods-in testing.
But expectations are changing. Software is no longer being sold to people who accept that software is inherently unreliable. It's not just that consumers are expecting more, but also the way that software is now often sold as components to be used in more software. More often than in the past, the customer is not the end user, but a savvy software engineer who knows that software can be tested and that bugs can be fixed, and who is himself under pressure to produce high-quality output in short time—pressure that they pass down to the supplier.