Skip to content

Instantly share code, notes, and snippets.

@sorahn
Last active September 15, 2023 17:54
Show Gist options
  • Save sorahn/905f67acf00d6f2aa69e74a39de65941 to your computer and use it in GitHub Desktop.
Save sorahn/905f67acf00d6f2aa69e74a39de65941 to your computer and use it in GitHub Desktop.
COMPUTER© 1980 ART 101 Limited, Atlanta Georgia - Kenneth Grooms

laws of computer programming

  • any given program, when running, is obsolete.
  • if a program is useless, it will have to be documented.
  • if a program is useful, it will have to be changed.
  • any program will expand to fill all available memory.
  • the value of a program is proportional to the weight of its output.
  • program complexity grows until it exceeds the capability of the programmer to maintain it.
  • make it possible for programmers to write in english and you will find that programmers cannot write in english.

rules of pratt

  • if a severe problem manifests itself, no solution is acceptable unless it is involved, expensive, and time consuming.
  • sufficient monies to do the job correctly the first time are not available; however ample funds are much more easily obtained for repeated revisions

grosch's law

  • computing power increases as the square of the cost increases. if you want to do it twice as cheaply, you have to do it four times a fast.
  • twenty percent of the components account for eighty percent of the cost, and so forth.

weinberg's law

  • if builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

hare's law of large programs

  • inside every large program is a small program struggling to get out.

turnaucka's law

  • the attention span of a computer is only as long as its electrical cord.

fallible men design fallible computers. a computer program does what you tell it to do, not what you want it to do.

troutmans programming laws

  • if a test installation functions perfectly, all subsequent systems will malfunction.
  • not until a program has been in production for at least six months will the most harmful error then be discovered.
  • job control cards that cannot be arranged in improper order will be.
  • interchangeable taps wont.
  • if the input editor has been designed to reject all bad input, an ingenious idiot will discover method to get bad data past it.
  • machines work, people should think.

golub's laws of computerdom

  • a carelessly planned project takes three times longer to complete than expected; a carefully planned project will take only twice as long.
  • the effort required to correct the error increases geometrically with the time.
  • project teams detest weekly progress reporting because it so vividly manifests their lack of progress.

hunt's law of suspense.

  • if any work has a suspense date on it, that work will be completed as close to the suspense date as possible, regardless of how far in advance it was programmed.

civilization advances by extending the number of important operations which we can do without thinking of them.

one good reason why computers can do more work than people is that they never have to stop and answer the phone.

bradley's bromide

  • if computers get too powerful, we can organize them into a committee - that will do them in.

the programmers nemesis

  • experts theorize that, through evolution and inbreeding, programmers may become a distinct subspecies of the human race.

law for the future

  • if it's not in a computer, it doesn't exist.

horgans homily

  • we won't have personal computing until we can get them little and talking.

wain's conclusion

  • the only people making money these days are the ones who sell computer paper.

first computer axiom

  • when putting it into memory, remember where you put it.

law of cybernetic entomology

  • there's always one more bug.

landau's programming paradox

  • the best programmer has to be someone.
  • the more humanlike a computer becomes, the less time it spends computing and the more time it spends doing more humanlike things.
  • a software committee of one is limited by its own horizon and will only specify that far.

extended epstein-heisenberg principle in a program atmosphere, only two of the three existing measurements can be measured simultaneously. the measurements are program, time, and resources.

  • if one knows what the task is, and there is a time limit allowed for the completion of the task, then one cannot guess how much it will cost.
  • if the time and resources are clearly defined, then it is impossible to know what part of the program will be performed.
  • if you are given a clearly defined program goal, and a definite amount of money which has been calculated to be necessary for the completion of the task, one cannot predict if and when the goal will be reached.
  • if one is lucky enough and can accurately define all three measurements, then what one deals with is not in the realm of programming

gallios's revelation.

  • if you put tomfoolery in a computer nothing come out but tomfoolery. but this tomfoolery, having passed through a very expensive machine, is somehow ennobled and none dare criticize it.

transcribed from images:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment