Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!oliveb!orc!bbn.com!drilex!dricejb From: dricejb@drilex.UUCP (Craig Jackson drilex1) Newsgroups: comp.arch Subject: Re: Bloat costs Message-ID: <11875@drilex.UUCP> Date: 5 Jun 90 13:44:53 GMT References: <2793@crash.cts.com> <265D2FE5.2513@tct.uucp> <640@sibyl.eleceng.ua.OZ> <2662CE6C.3E68@tct.uucp> <26798@eerie.acsu.Buffalo.EDU> <25444.2667fff8@ccavax.camb.com> <90Jun4.103308edt. Organization: DRI/McGraw-Hill, Lexington, MA Lines: 14 As someone who has been programming for fifteen years or so, I can well appreciate the value of tight programming. However, there is such a thing as too-tight progamming. The use of too-small field widths was one problem noted. Another problem, which I believe is just as severe, is the tendency to leave out assertion-checking and internal debugging support in "finished" code. I'm a firm believer in checking lots of assumptions early and often, even in production code. Also, it's useful to have lots of hidden debugging capabilities. All too often, when you were trying to squeeze in another feature, it was a print statement that died. -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}