Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!yale!bunker!garys
From: garys@bunker.UUCP (Gary M. Samuelson)
Newsgroups: comp.lang.c
Subject: Re: Programmers who "aren't allowed" to do things right
Message-ID: <2396@bunker.UUCP>
Date: Mon, 13-Jul-87 10:33:53 EDT
Article-I.D.: bunker.2396
Posted: Mon Jul 13 10:33:53 1987
Date-Received: Tue, 14-Jul-87 03:38:08 EDT
References: <598@nonvon.UUCP> <2365@bunker.UUCP> <1656@tekig4.TEK.COM>
Reply-To: garys@bunker.UUCP (Gary M. Samuelson)
Organization: Bunker Ramo an Olivetti Company, Shelton CT
Lines: 42

In article <1656@tekig4.TEK.COM> bradn@tekig4.UUCP (Bradford Needham) writes:
>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.

I am not trying to justify it, just explain it.  Doing it right in
spite of the pressures shows up in your annual review as negative.

>It is the engineer's responsibility to give his manager his best guess at
>technical "reality"...

Well, first, the manager has to ask for that input, and then, the manager
has to accept the engineer's assessment as valid, and then, the manager
has to convince the next manager(s) up that the end date dictated by Marketing
can't be met.

>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.

I am not sure that the two are mutually exclusive.  If the marketing
department were adept at their job, they would be able to anticipate
what the customer is going to need in time for the engineering department
to design, build, and test it (I left out "document," because I consider
writing documentation to be an integral part of each of the other
activities mentioned -- e.g., the result of designing is a design document --
but that's a nit).  And if the engineering department were adept at their
job, they would have, among other things, a set of "building block"
software from which they could build most of any new product.  Only
the parts which were really new (and there isn't that much new in any
given new product) would require new design.

Gary K2 el	 8 8