Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!mit-eddie!uw-beaver!tektronix!tekig!tekig4!bradn From: bradn@tekig4.TEK.COM (Bradford Needham) Newsgroups: comp.lang.c Subject: Programmers who "aren't allowed" to do things right Message-ID: <1656@tekig4.TEK.COM> Date: Fri, 10-Jul-87 17:41:05 EDT Article-I.D.: tekig4.1656 Posted: Fri Jul 10 17:41:05 1987 Date-Received: Sun, 12-Jul-87 13:14:29 EDT References: <598@nonvon.UUCP> <2365@bunker.UUCP> Reply-To: bradn@tekig4.UUCP (Bradford Needham) Organization: Tektronix, Inc., Beaverton, OR. Lines: 26 In article <2365@bunker.UUCP> garys@bunker.UUCP (Gary M. Samuelson) writes: >Well, there is a third class [of programmers who write poorly-commented code]. >Some of us are actually not permitted to "do it right." >Out in the "real world," as they called it when I was still a student, >we have things called schedules and deadlines. While I agree that the real world exerts strong pressures to do things "the wrong way", and while I sympathize with every programmer that suffers under an inflexible, counterproductive organization, I don't agree that these pressures justify producing poorly-documented code. It is the engineer's responsibility to give his manager his best guess at technical "reality": how long things are going to take; how risky a certain feature or method is; what tradeoffs exist between time-to-market, product features, and product quality. Without this input, the manager is going to make unrealistic decisions. I agree that there has to be compromise between programming heaven (where there is plenty of time to thoroughly design, document, build, and test) and sales heaven (where products appear the moment a customer asks for them). Achieving a good compromise (a good-quality product in a timely manner) is the mark of a good engineer. Brad Needham bradn@tekig4.TEK.COM