Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "John B. Matthews" Newsgroups: comp.lang.java.programmer Subject: Re: Space probes was Re: in praise of type checking Date: Fri, 14 Oct 2011 07:09:50 -0400 Organization: The Wasteland Lines: 57 Message-ID: References: <7sudncbWtOTsrQjTnZ2dnUVZ876dnZ2d@telenor.com> <9LqdnfdVAsdGkQvTnZ2dnUVZ876dnZ2d@telenor.com> NNTP-Posting-Host: LQJtZWzu+iKlBROuDg+IUg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) X-Notice: Filtered by postfilter v. 0.8.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8782 In article , Arved Sandstrom wrote: > On 11-10-13 02:08 AM, Leif Roar Moldskred wrote: > > Gene Wirchenko wrote: > >> > >> Sure there was. It had an assumption about how much oomph the > >> rocket had. The Ariane 5 had way more than the 4 did. With the > >> 4, the overflow was not possible. With the 5, it was. > > > > Yes, but as the code wasn't written to be used on the Ariane 5, > > that was a valid assumption and not an error. The code was correct > > and fit for its intended use. That someone later took this code and > > tried to use it for something it was never meant to be used for is > > not an error in the code: A wrench makes a poor hammer, but that > > doesn't mean the wrench is constructed badly. > > > When I read the report that Martin pointed us at, particularly pages > 4-6 (pages 8-10 of the PDF), I sure don't get the impression that the > code was "correct and fit for its intended use". This includes in a > wider sense the documentation that describes the assumptions and > decisions related to the code. > > How do you know that the code was not meant to be used for the Ariane > 5? They _did_ use it for the Ariane 5; that's enough evidence for me > that they intended for it to be used not just for the Ariane 4 but > also for the Ariane 5. The report clearly states that the reasoning > related to the horizontal bias variable BH was *faulty* - they just > happened to be fortunate with Ariane 4. It was not, as you suggest, a > "valid assumption". And the follow-up exception-handling was > described as a systematic software design error. I inferred that BH was left unprotected to reduce delay in the "event of a hold in the count-down," a feature used in Ariane 4. "The same requirement does not apply to Ariane 5." The "systematic software design error" was a culture of "only addressing random hardware failures." The management error was in not thoroughly testing the reused software. > In a wider sense, if you've got a codebase that was intended for > situation A (or more precisely, since "intended" is a strong > purposeful word that implies knowing what you're about, "used with"), > and now you adopt it for situation B, that codebase _belongs_ to > situation B. You can't say it's fit and correct just because it still > works in situation A - who cares, actually? If it's unfit for > situation B it's unfit for situation B. Period. A Java analogy might be adopting a 10 year old external dependency without running _all_ unit tests. "No reference to justification of [the BH] decision was found directly in the source code." I can't help but think that generated documentation (e.g javadoc, adahtml) is one way to mitigate this kind of risk. -- John B. Matthews trashgod at gmail dot com