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