[comp.lang.c] Programmers who "aren't allowed" to do things right

bradn@tekig4.TEK.COM (Bradford Needham) (07/11/87)

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

garys@bunker.UUCP (Gary M. Samuelson) (07/13/87)

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

rha@bunker.UUCP (The Minister of Myrth) (07/13/87)

In article <1656@tekig4.TEK.COM> bradn@tekig4.UUCP (Bradford Needham) writes:

>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, I think that Gary, and others here at Bunker, exemplify what you
are talking about.  In other words, estimates which emanate from the Engineer
include all facets of the development process (including documentation).  In
addition, the Engineering Supervisors typically support these estimates.

     What Gary is talking about is that, by the time the various big cheeses
get their hands on the estimates and label them as "unacceptable" (although
NO functionality is disposable), what invariably gets killed, in the name of
"expedience" (we know this isn't true), is documentation.

     Therefore, I suggest to you that a "good engineer" may have all the right
intentions and informs all the right people, while it is only the "influential
engineer" who actually get to the ear drum of the decision makers.


-- 
                       {yale!,decvax!,philabs!}bunker!rha                    
                                  Bob Averack                           
                        Bunker Ramo, an Olivetti Company                      
               Two Enterprise Drive - Shelton, Connecticut 06484             

gwl@rruxa.UUCP (George W. Leach) (07/15/87)

In article <2396@bunker.UUCP>, garys@bunker.UUCP writes:
> 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.

     Personal and professional pride dictate doing it right (or trying
to) anyway!

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


       Everyone in a company must be committed to doing it right!  Not
just the programmer, but management, the customers, everyone!!!!  It is
too easy to promise the customer the world, with little preliminary
work to adequately define just what it is that the customer wants.  Then
as time marches on and it become obvious that dates will be slipped, the
first thing that everyone drops are the quality arrangements that were
set up.  For example, design and code reviews were the first thing to
go!  Then features are dropped, then corners are cut!!!!
 
 
      The problem is in short term thinking on the part of too many
people.  How often have you seen people make decisions and promises
that just are not reasonable.  Then they are promoted before the SH*T
hits the fan!!!!  Ever see the "6 Phases of a Project" sign?  The
very last one is "Praise and Honors for the Non Participants".  Oh,
how true!!!  If when a project team is put together, it was made clear
that all members of the team would be there for the duration of the
project, then you would have a great deal more interest in doing it
right.  Too often short sighted politics gets in the way.  Manager X
wants to use this project for the visability it will provide to get
him/her a promotion.  If all works right, promise all sorts of things
and you will get that promotion before the promises must be realized!
Don't laugh, it happens far too frequently.


      But why not?  Afterall, isn't this the way that our government
leaders operate as well?????   Next election.


George W. Leach

Bell Communications Research      New Jersey Institute of Technology 
444 Hoes Lane       4A-1129       Computer  &  Information Sciences Dept.
Piscataway,  New Jersey   08854   Newark, New Jersey   07102
(201) 699-8639

UUCP:  ..!bellcore!{indra | yogi | njitcis}!reggie
ARPA:  reggie%njit-eies.MAILNET@MIT-MULTICS.ARPA

From there to here, from here to there, funny things are everywhere
Dr. Seuss "One fish two fish red fish blue fish"

gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/16/87)

Another common problem is that companies attempt to provide what the
customer THINKS he wants, rather than what the customer REALLY wants.
Satisfying the latter need should be the goal of a rational company,
but it requires effort to determine what is really needed.  I tend
to give my business to companies that I perceive taking the latter
approach, and I suspect enough other people do also that it would
make good business sense for any company with limited clientele.
Those selling to the "mass market" cannot of course work directly
with their customers, even at the dealer level, so this approach may
not make sense for companies in such a position.