Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!voder!pyramid!athertn!hemlock!mcgregor From: mcgregor@hemlock.Atherton.COM (Scott McGregor) Newsgroups: comp.software-eng Subject: Re: Reusability considered harmful??(!!) Message-ID: <34483@athertn.Atherton.COM> Date: 19 Feb 91 18:18:21 GMT References: <88431@tut.cis.ohio-state.edu> <6108@stpstn.UUCP> <87829@tut.cis.ohio-state.edu> <6248@stpstn.UUCP> <1991Feb11.103100.112@skyler.mavd.honeywell.com> <34464@athertn.Atherton.COM> Sender: news@athertn.Atherton.COM Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor) Organization: Atherton Technology -- Sunnyvale, CA Lines: 66 > The odd thing is, people worry about testing inherited code, but they > are looking at it wrong, I think. If you have gotten some software that > asserts it can be inherited from, you should treat that software like > an IC. You don't second-guess Intel, right? If the software DOES break, > it should be something you can take to the courts, just as a chip that > failed to perform to spec would be grounds for restitution. You may not second guess Intel, but I can assure you that when before you commit to a particular hardware design you build a breadboard prototype and test the joint suitability of the components you have selected. It is very likely that you will unit test some components even before that stage. The reason is not that you don't trust the vendor, but that there are so many variables that might interact in unforseen ways, and because your particular use may rely on a very special aspect of what the IC can do. The discussion of Tolerances is relavant, in that your particular design may be more or less tolerant to small differences in voltage, capitance, etc. Note that this most particularly the problem for the many small infrequently chosen components. It is true that the more you get in the habit of reusing the same component the more you have already tested it, and so the more you can trust it. A 386 might be the heart of many designs and so well understood and tested, but how about various special purpose chips: DtoAs, AtoDs, board-to-bus linkages chips for creating packets for networks, audio, video, pattern recognition chips... Many of the chips are of the mundane variety, but specially chosen for that particular board, and the designer may have to refer to many manuals to chose among many possible selections. They won't be sure until they test it. The same situation holds for software. Testing an inherited component is necessary not because you don't trust (or because you second guess) it's designer. But because it is the only way to verify that it will behave exactly the way you expect in the EXCEPTIONAL CIRCUMSTANCES of your particular application, and be sure that you were correct in your assumption of it's suitability. Common things like "strcat" may be easy to understand and verify their suitability for your use. But more complex things like "performs a branch flow coverage test over software in question" have many more degrees of freedom to test and more sources of confusion or misconnected expectations between software IC developer and consumer. > Until people get comfortable with the idea of off-the-shelf software being > just as much of a black box as ANY OTHER COMMODITY, we will continue to > battle this weird behavior. Do you second guess anything else you buy? > No? Then why second-guess software modules? My developers *do* treat inherited code much the same as other commodities. Sometimes it gets us in trouble when it doesn't act the way we expected it to (or said in a different way, when we don't expect it to act the way it actually does). So we have to test it to prevent later errors. In other more mature commodity markets there are established test labs with publishing arms (e.g. Consumer Reports) that can carry some of the burden. But note that when you get to a commodity with as much variation and complexity as an automobile, then even Consumer Reports recommends that you test drive it first and not just order one by phone from an autobroker and have it delivered. The problem is not just getting people to treat inherited code like other commodities, but that people are tempted to assume that they can treat it as even more homogenous than other commodities--tempting them to skip over necessary incoming verification for suitability of use. This leads to many unfortunate design problems not detected until final QA or until expensive failures in the field. Scott McGregor Atherton Technology mcgregor@atherton.com