861087a@aucs.uucp (Andreas Pikoulas) (02/27/90)
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.
Thanks in advance
A n d r e a s
Andreas Pikoulas| UUCP :{uunet|watmath|utai|garfield}!cs.dal.ca!aucs!861087a
TOWER 410 | E-MAIL : 861087a@AcadiaU.CA
WOLFVILLE-NS | Phone(voice) : (902) 542-5623
CANADA B0P 1X0 | ------- IF YOU CAN'T CONVINCE THEM, CONFUSE THEM. --------
****************************************************************************sed@sppy00.UUCP (Steve Driscoll) (02/27/90)
It depends on what you call creative. If creativity is finding new ways to make a program run more effective (faster, more reliably, etc.) then by all means, be creative. If you mean to run off on your own to build the finest, most elegant solution to some problem, regardless of what is specified or in spite of time schedules then I'd say I could do without the creativity. -- *** ** * | | OO CC L CC // *** ** * | | O O C L C // *** ** * | | O O C L C // *** ** * | | OO CC LLL CC // Bringing information to people!
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (02/28/90)
After a few years in the field, I have come to a personal commitment to practice good craftsmanship in everything I do. If a program is worth writing it is worth writing well. It requires great creativity to design and write good software. It also results in good business, because good software has fewer problems, and this results in less maintenance cost. The programming standards of an organization don't stifle creativity, at least not the creativity of a disciplined craftsman, any more than they would in say, a cabinet shop. -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
gwyn@smoke.BRL.MIL (Doug Gwyn) (02/28/90)
In article <25eb63c7.6a42@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes:
-After a few years in the field, I have come to a personal commitment to
-practice good craftsmanship in everything I do. If a program is worth
-writing it is worth writing well. It requires great creativity to design
-and write good software. It also results in good business, because good
-software has fewer problems, and this results in less maintenance cost.
All that is fine, and hurray for you.
-The programming standards of an organization don't stifle creativity, at
-least not the creativity of a disciplined craftsman, any more than they
-would in say, a cabinet shop.
Now, THAT depends on the standards. It definitely is not true that ANY
standard is better than none. For example, DoD contracts call for really
stupid deliverables, including documentation conforming to coding standards
that a good, experienced software craftsman would not voluntarily obey.doerschu@rex.cs.tulane.edu (David Doerschuk) (02/28/90)
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
jcp@decuac.DEC.COM (Jolly C. Pancakes) (03/01/90)
In article <2317@rex.cs.tulane.edu>, doerschu@rex.cs.tulane.edu (David Doerschuk) writes: > 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. Another book that I would highly recommend is one that came out a little over a year ago - "Peopleware" by Tom DeMarco and another author. It concentrates on workgroup theories and the creative nature of programming (and makes some great arguments against mandatory neckties and..... The Furniture Police !). -- jcpatilla jcp@decuac.dec.com "Fling your beavers aloft!"
ggw@wolves.uucp (Gregory G. Woodbury) (03/03/90)
In article <1990Feb26.234217.23251@aucs.uucp> 861087a (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. Despite the note about e-mail elaboration, I think this really needs to be aired publicly. Here is my response.... There are two main problems with this attitude. 1) It assumes that computer programming is dealing with some exact problem that has exactly one correct solution. 2) It assumes that the bricklayer reading a blueprint for a building wall will have nothing inexact or creative to do. To pick up the 2nd point first. The "average" bricklayer (if such a person exists) may not have to challenge his ingenuity over 90% or so of a strech of wall. But, the particular patterning of bricks around a window or door, especially if the opening is of a non-conventional shape, may require a great deal of ingenuity and problem-solving. To add to the situation, sometimes the architects patterning of brick colors, or even the use of stonework other than the rectangular regularity of brick, may require several hours of thought before the placement of a particular stone, or even in the selection of which stone to put where! I have tried my hand at both bricklaying and stonemasonry (there is a difference!). I enjoyed it (except for climbing ladders) but discovered that I could earn more by sitting inside and programming computers for a living. The author exhibits the usual elitist attitude that the "blue collar" trades do not require creativity or ingenuity. A little bit of "on-the-job" research would show him why a master carpenter or a master stonemason can earn as much or more than a programmer. Now, back to point 1. In the "average" programming situation (if there is such a thing) there are probably "usual and customary" algorithims and procedures that will do what is necessary. But, in certain situations, especially when dealing with a new class of problem, or in implementing a newly invented technique (e.g. a new statistical tool or writing a compiler for a new computer architecture) the situation may require a lot of thought and ingenuity (read creativity) to "do the right thing". To add to the situation, the architects of the system may impose specific coding or documentation standards that may require several hours (or days) of thought in order to determine how to code within the requirements. I suspect that the original quotation, lifted out of its context is badly misrepresenting the authors intention. If he is trying to say that ALL PROGRAMMING is just routine laying down of one brick after another, then he is insulting the profession. On the other hand, if he is (as I suspect) classifying only a certain aspect of programming (i.e. the development of accounting packages) then he may be correct. I would like to have a little more context for this particular quotation. -- Copyright 1990, Gregory G. Woodbury, electronic re-distribution allowed -- Gregory G. Woodbury Sysop/owner Wolves Den UNIX BBS, Durham NC UUCP: ...dukcds!wolves!ggw ...dukeac!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw@ac.duke.edu ggw%wolves@ac.duke.edu Phone: +1 919 493 1998 (Home) +1 919 684 6126 (Work) [The line eater is a boojum snark! ] <standard disclaimers apply>
dritchey@cbnewsc.ATT.COM (don.ritchey) (03/08/90)
in article <1990Mar3.065257.13674@wolves.uucp>, ggw@wolves.uucp (Gregory G. Woodbury) says: > In article <1990Feb26.234217.23251@aucs.uucp> 861087a (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. " >> > Despite the note about e-mail elaboration, I think this really needs > to be aired publicly. Here is my response.... > > There are two main problems with this attitude. > 1) It assumes that computer programming is dealing with some exact problem > that has exactly one correct solution. > 2) It assumes that the bricklayer reading a blueprint for a building wall > will have nothing inexact or creative to do. > I read this quote and the response to it a little differently. The main problem that I have seen in maintaining other people's software is excessive creativity where it is not appropriate (which is what I think the author probably intended to say). When the plan calls for simple "brickwork" with no need for fancy, convoluted "creative" code, then the programmer should write simple, non-creative code. When the time comes for the programmer to have to work around the "windows" and "doors" of the code, where the "brickwork" gets more complex, then the need arises for finding creative solutions to complex problems. What I suspect we need is what I would call "disciplined programming", which is not a blanket condemnation of "creativity", but a knowledge of when creativity is necessary. A well disciplined programmer knows how to use the conventions of coding style that places the punctuation in the expected places, follows the project guidelines for indentation and commenting, and rejects the desire to show off when the need simply isn't there. For example: If space is not a critical resource, then there is no need for fancy data packing and unpacking functions that consume run time and may actually use more memory (due to the size of the function) than they save. Similar analogies can be made for other cases. On the other hand, when creativity is essential (to overcome some limitation such as process run time, lack of heap space, or whatever) the well disciplined programmer writes the "creative code" as clearly and as cleanly as possible. The more creative and convoluted the code must be to overcome the obstacle, the greater the need for explanations and in-progress comments to let the maintenance programmer figure out what was done and how. It also helps the programmer figure out what he or she was doing when the inevitable requirement comes in to add some enhancement to that same creative code that was written 6 months ago. If the problem is sufficiently complex, the programmer may have to start from scratch to figure out "What did I do, and why did I do it THAT way." I don't think that the author of the book intended for the programmer to write code while within a straight jacket, but instead for the programmer to develop a sense of discipline of how to follow the rules of the project, and know when and how to successfully break the rules. Just like the Burger King commercial, "Sometimes you just got to break the rules!". That doesn't mean you have to break the rules all the time. For whatever that was worth, there it is. #include <std/disclaimer.h> Don Ritchey dritchey@ihlpb.att.com or don.ritchey@att.com AT&T Bell Labs, Room IH 1D-409, Naperville, IL 60566, (708) 979-6179 :-) The advice you get here is worth all that you paid for it. :-)
maclean@bcarh186.bnr.ca (Mark Maclean) (03/14/90)
In article <14203@cbnewsc.ATT.COM> dritchey@cbnewsc.ATT.COM (don.ritchey) writes: >main problem that I have seen in maintaining other people's software is >excessive creativity where it is not appropriate > >On the other hand, when creativity is essential (to overcome some >limitation such as process run time, lack of heap space, or whatever) >the well disciplined programmer writes the "creative code" as clearly >and as cleanly as possible. The more creative and convoluted the code ^^^^^^^^^^^^^^^^^^^^^^^ >must be to overcome the obstacle, the greater the need for explanations >and in-progress comments to let the maintenance programmer figure out >what was done and how. It also helps the programmer figure out what he Creative programming, for me at least, usually involves trying to simplify the problem as much as possible. If the code is extremely convoluted then it is entirely likely that the programmer was not creative enough. Creativity is a must for creating good, maintainable code. K.I.S.S. requires creativity too. - The above are not the opinions of my species, my country, or my employer. If you disagree with them then they are not your opinions either!
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (03/15/90)
In article <2308@bnr-rsc.UUCP> bnr-rsc!bcarh186!maclean () writes: >Creative programming, for me at least, usually involves trying to simplify >the problem as much as possible. Yes!! >If the code is extremely convoluted then it is entirely likely that the >programmer was not creative enough. Creativity is a must for creating >good, maintainable code. I agree heartily. Convoluted code is *never* the best solution to any programming problem. In my programming, the only convoluted code I have ever allowed in my work was stuff that somebody else wrote and I didn't have time to fix. Maintaining "creative" code takes the creativity that the one who wrote it didn't have in the first place. -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
jeffa@hpmwtd.HP.COM (Jeff Aguilera) (03/16/90)
> The > main problem that I have seen in maintaining other people's software is > excessive creativity where it is not appropriate (which is what I think > the author probably intended to say). When the plan calls for simple > "brickwork" with no need for fancy, convoluted "creative" code, then > the programmer should write simple, non-creative code. I maintain a LOT of code. The main problem is not creativity of the implementation, but rather lack of a plan.
rang@cs.wisc.edu (Anton Rang) (03/18/90)
In article <25fed2fe.1f3e@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >In article <2308@bnr-rsc.UUCP> bnr-rsc!bcarh186!maclean () writes: >>If the code is extremely convoluted then it is entirely likely that the >>programmer was not creative enough. Creativity is a must for creating >>good, maintainable code. > >I agree heartily. Convoluted code is *never* the best solution to any >programming problem. I think someone pointed out earlier that there are times when convoluted code is necessary to satisfy some constraints of the problem. Especially when working on microcomputers, these seem to pop up once a year or so in the stuff I do. If you have an interrupt handler with a critical time constraint, for instance, you may have to put some real convolutions into the code to get it to run quickly enough. (This involves a lot of creativity, too--just a different kind.) Another example is working with a program with 150K of free memory and 2 MB of data, when some operations scan every record, but only a particular field--it's convoluted to maintain an array in memory which parallels part of the records stored on disk, but it may mean the difference between a program which is too slow to use and one which is workable. >Maintaining "creative" code takes the creativity that the one who >wrote it didn't have in the first place. If it's properly documented, it's not necessarily too bad. I try to avoid convolution, and when I'm writing a program I try to do it the most straightforward way. If I find something which forces me into doing convolution, I'll keep the (unconvoluted) algorithm in the docs, along with an explanation of what "tricks" have been used, and why. I've gone back to programs like this I've written, 7 or 8 years later, and (after perusing the documentation for a few minutes) it's not hard to change them. Just my $.02.... Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+