Xref: utzoo comp.unix.wizards:20809 comp.misc:8353 comp.sys.ibm.pc:45396
Path: utzoo!attcan!uunet!ogicse!uwm.edu!rpi!brutus.cs.uiuc.edu!samsung!rex!doerschu
From: doerschu@rex.cs.tulane.edu (David Doerschuk)
Newsgroups: comp.unix.wizards,comp.misc,comp.sys.ibm.pc
Subject: Re: The *ART* of Computer Programming
Message-ID: <2317@rex.cs.tulane.edu>
Date: 28 Feb 90 15:55:24 GMT
References: <1990Feb26.234217.23251@aucs.uucp>
Reply-To: doerschu@rex.UUCP (David Doerschuk)
Organization: Computer Science Dept., Tulane Univ., New Orleans, LA
Lines: 49
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <1990Feb26.234217.23251@aucs.uucp> 861087a@aucs.UUCP (Andreas Pikoulas) writes:
>
>    From Paul Tom's book "Computer Information Systems" page 169
>
>   " Not only do organizations standarize programming languages, they also
>develop coding styles so that programs written by different programmers
>all follow good coding conventions. While SOME consider programming a
>"creative activity", a programmer should be as creative as a bricklayer
>following a blueprint for building a wall on a house. Creative programming
>, like accounting , can only get the user into trouble. "
>
>Please elaborate on this by e-mail. I plan to send your answers to the
> author.
>Andreas Pikoulas| UUCP :{uunet|watmath|utai|garfield}!cs.dal.ca!aucs!861087a

Mr. Tom is describing an old problem and trying to use a sledgehammer to
solve it.  If programming tasks were as simple as he describes; we would
have developed methods for directly mapping the requirements onto finished
code.  There is research going on now directed towards "natural language
compilers", but the problems are significant and (IMHO) not completely
solveable.  *Very* interesting stuff, though.

He (Tom) doesn't define "creative programming"; so I can't comment on
whether I think its bad or not!  Certainly there are constructs and
techniques that should be avoided:  relying on undocumented features
of the OS, self-modifying code, etc. but to relieve programmers of all
creative tasks would seem to be self-defeating...all your most productive
programmers would quit!

Managing programmers and dividing tasks between architects and programmers
is an art/science.  For a somewhat more enlightened and realistic account,
I strongly recommend Frederick P. Brooks' book: "The Mythical Man-month".
Brooks ran the OS/360 project at IBM in the middle 1960's, and his book
describes the things he learned during this mammoth task.  He's a very
smart guy, and his experiences are *highly relevant* to modern programming.

In summary, for what its worth, here's what I think:
1.  Anyone who thinks that programmers involved in a commercial development
    situation should be able to do any damn thing they want is dead wrong.
2.  Anyone who thinks that creativity should be suppressed in ANY employee
    (much less PROGRAMMERS, for god's sake!) is crazy.

Thank's for the bandwidth!  BTW, is Tom's book current?  It sounds dated,
like something from back in the late 60's or early 70's when some of the
big corporate jobs were getting out of hand and a discipline (ANY
discipline!) was being looked for to control the mess.

Dave Doerschuk
doerschu@rex.cs.tulane.edu