I should wish, as do most men, that immutable truths existed, that not all would be eroded by the impact of historical time, that there were some essential propositions, be it only in the field of human values, the basic values, etc. In brief, I long for the absolute. But at the same time I am firmly convinced that there are no absolutes, that everything is historical, and that you cannot get away from history.

A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

Everything is scriptable, whether the author intended it to be or not.

Everything is a file.

Policy is not decided for you, or reasonable defaults are decided that you can replace with your own.

Be responsible for what you're doing. You won't be second guessed and prompted. This is the price you pay for simplicity and an environment that isn't dumbed down.

Configuration is done via text files that you can edit without complicated tools. Whenever sensible, data is in text files too.

You can do complicated things by gluing simple things together.

Simple and consistent interfaces are good, but they do not generally excuse large and complex implementations. Complex systems are built on simple cores and not vice versa.

Simple and complex systems are better separated from each other, leading to layered rather than monolithic design.

Write a script first.

Anything should be possible to be automated.

You can break any of these rules.

Elegance.

Few arbitrary or adjustable elements.

Agrees with and explains all existing observations.

Makes detailed predictions about future observations that can disprove or falsify the model if they are not borne out.

Strive For Consistency

• Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout.

Enable Frequent Users To Use Shortcuts

• As the frequency of use increases, so do the user's desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user.

Offer Informative Feedback

• For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial.

Design Dialog To Yield Closure

• Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions.

Offer Simple Error Handling

• As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error.

Permit Easy Reversal Of Actions

• This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.

Support Internal Locus Of Control

• Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.

Reduce Short-term Memory Load

• The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.

Technology should require the smallest possible amount of attention

• Technology can communicate, but doesn’t need to speak.
• Create ambient awareness through different senses.
• Communicate information without taking the wearer out of their environment or task.

Technology should inform and create calm

• A person's primary task should not be computing, but being human.
• Give people what they need to solve their problem, and nothing more.

Technology should make use of the periphery

• A calm technology will move easily from the periphery of our attention, to the center, and back.
• The periphery is informing without overburdening.

Technology should amplify the best of technology and the best of humanity

• Design for people first.
• Machines shouldn't act like humans.
• Humans shouldn't act like machines.
• Amplify the best part of each.

Technology can communicate, but doesn’t need to speak

• Does your product need to rely on voice, or can it use a different communication method?
• Consider how your technology communicates status.

Technology should work even when it fails

• Think about what happens if your technology fails.
• Does it default to a usable state or does it break down completely?

The right amount of technology is the minimum needed to solve the problem

• What is the minimum amount of technology needed to solve the problem?
• Slim the feature set down so that the product does what it needs to do and no more.

Technology should respect social norms

• Technology takes time to introduce to humanity.
• What social norms exist that your technology might violate or cause stress on?
• Slowly introduce features so that people have time to get accustomed to the product.

Sans-serif fonts are usually more legible than fonts with serifs.

Avoid using a font that has characters that are too similar to one another, as this will reduce the legibility of the print.

Avoid using dot matrix print for critical flight-deck documentation.

Long chunks of text should be set in lower case.

If upper case is required, the first letter of the word should be made larger in order to enhance the legibility of the word.

When specifying font height, or accessing graphs to determine the size of a lower-case character, the distinction between “x” height and overall size should be made.

As a general recommendation, the “x” height of a font used for important flight-deck documentation should not be below 0.10 inch.

The recommended height-to-width ratio of a font that is viewed in front of the observer is 5:3.

The vertical spacing between lines should not be smaller than 25–33% of the overall size of the font.

The horizontal spacing between characters should be 25% of the overall size and not less than one stroke width.

Avoid using long strings of text set in italics.

Use primarily one or two typefaces for emphasis.

Use black characters over a white background for most cockpit documentation.

Avoid using white characters over a black background in normal line operations. However, if this is desired: Use minimum amount of text, use relatively large typesize, and use sans-serif to minimize the loss of legibility.

Black over white or yellow are recommended for cockpit documentation.

Avoid using black over dark red, green, and blue.

Use anti-glare plastic to laminate documents.

Ensure that the quality of the print and the paper is well above normal standards. Poor quality of the print will effect legibility and readability.

The designer must assess the age groups of the pilots that will be using the documentation, and take a very conservative approach in assessing information obtained from graphs and data books.

Explicit is better than implicit.

Beautiful is better than ugly.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one, and preferably only one, obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than *right* now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!

Engineering is done with numbers. Analysis without numbers is only an opinion.

To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong .

Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.

Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.

(Miller's Law) Three points determine a curve.

(Mar's Law) Everything is linear if plotted log-log with a fat magic marker.

In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.

Not having all the information you need is never a satisfactory excuse for not starting the analysis.

When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along.

Sometimes, the fastest way to get to the end is to throw everything out and start over.

There is never a single right solution. There are always multiple wrong ones, though.

Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.

The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours.

The fact that an analysis appears in print has no relationship to the likelihood of its being correct.

Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though.

The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up.

A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.

(Larrabee's Law) Half of everything you hear in a classroom is crap. Education is figuring out which half is which.

When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)

The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it.

It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.

(Bowden's Law) Following a testing failure, it's always possible to refine the analysis to show that you really had negative margins all along.

(Montemerlo's Law) Don't do nuthin' dumb.

(von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.

(von Tiesenhausen's Law of Engineering Design) If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept.

(Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees.

(Atkin's Law of Demonstrations) When the hardware is working perfectly, the really important visitors don't show up.

Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.

(Henshaw's Law) One key to success in a mission is establishing clear lines of blame.

Capabilities drive requirements, regardless of what the systems engineering textbooks say.

Any exploration program which "just happens" to include a new launch vehicle is, de facto, a launch vehicle program.

(alternate formulation) The three keys to keeping a new manned space program affordable and on schedule:

• No new launch vehicles.
• No new launch vehicles.
• Whatever you do, don't develop any new launch vehicles.

(McBryan's Law) You can't make it better until you make it work.

Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there's no partial credit because most of the analysis was right...)

Every good work of software starts by scratching a developer's personal itch.

Good programmers know what to write. Great ones know what to rewrite (and reuse).

Plan to throw one [version] away; you will, anyhow.

If you have the right attitude, interesting problems will find you.

When you lose interest in a program, your last duty to it is to hand it off to a competent successor.

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

Release early. Release often. And listen to your customers.

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

Smart data structures and dumb code works a lot better than the other way around.

If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.

The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.

Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.

When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!

When your language is nowhere near Turing-complete, syntactic sugar can be your friend.

A security system is only as secure as its secret. Beware of pseudo-secrets.

To solve an interesting problem, start by finding a problem that is interesting to you.

Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

People have exactly one canonical full name.

People have exactly one full name which they go by.

People have, at this point in time, exactly one canonical full name.

People have, at this point in time, one full name which they go by.

People have exactly N names, for any value of N.

People’s names fit within a certain defined amount of space.

People’s names do not change, or at least only at a certain enumerated set of events.

People’s names are written in ASCII.

People’s names are written in any single character set.

People’s names are all mapped in Unicode code points.

People’s names are case sensitive.

People’s names are case insensitive.

People’s names sometimes have prefixes or suffixes, but you can safely ignore those.

People’s names do not contain numbers.

People’s names are not written in ALL CAPS.

People’s names are not written in all lower case letters.

People’s names have an order to them. Picking any ordering scheme will automatically result in consistent ordering among all systems, as long as both use the same ordering scheme for the same name.

People’s first names and last names are, by necessity, different.

People have last names, family names, or anything else which is shared by folks recognized as their relatives.

People’s names are globally unique.

People’s names are almost globally unique.

Alright alright but surely people’s names are diverse enough such that no million people share the same name.

My system will never have to deal with names from China, Japan, Korea, Ireland, the United Kingdom, the United States, Spain, Mexico, Brazil, Peru, Russia, Sweden, Botswana, South Africa, Trinidad, Haiti, France, or the Klingon Empire, all of which have “weird” naming schemes in common use.

Confound your cultural relativism! People in my society, at least, agree on one commonly accepted standard for names.

There exists an algorithm which transforms names and can be reversed losslessly.

I can safely assume that this dictionary of bad words contains no people’s names in it.

People’s names are assigned at birth.

OK, maybe not at birth, but at least pretty close to birth.

Two different systems containing data about the same person will use the same name for that person.

Two different data entry operators, given a person’s name, will by necessity enter bitwise equivalent strings on any single system, if the system is well-designed.

People whose names break my system are weird outliers. They should have had solid, acceptable names, like 田中太郎.

People have names.

Restrict all code to very simple control flow constructs – do not use goto statements, setjmp or longjmp constructs, and direct or indirect recursion.

All loops must have a fixed upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.

Do not use dynamic memory allocation after initialization.

No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function.

The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule. (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements.)

Data objects must be declared at the smallest possible level of scope.

The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function.

The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives is often also dubious, but cannot always be avoided. This means that there should rarely be justification for more than one or two conditional compilation directives even in large software development efforts, beyond the standard boilerplate that avoids multiple inclusion of the same header file. Each such use should be flagged by a tool-based checker and justified in the code.

The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.

All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings.

One man's constant is another man's variable.

Functions delay binding: data structures induce binding. Moral: Structure data late in the programming process.

Syntactic sugar causes cancer of the semi-colons.

Every program is a part of some other program and rarely fits.

If a program manipulates a large amount of data, it does so in a small number of ways.

Symmetry is a complexity reducing concept (co-routines include sub-routines); seek it everywhere.

It is easier to write an incorrect program than understand a correct one.

A programming language is low level when its programs require attention to the irrelevant.

It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.

Get into a rut early: Do the same processes the same way. Accumulate idioms. Standardize. The only difference (!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.

If you have a procedure with 10 parameters, you probably missed some.

Recursion is the root of computation since it trades description for time.

If two people write exactly the same program, each should be put in micro-code and then they certainly won't be the same.

In the long run every program becomes rococco - then rubble.

Everything should be built top-down, except the first time.

Every program has (at least) two purposes: the one for which it was written and another for which it wasn't.

If a listener nods his head when you're explaining your program, wake him up.

A program without a loop and a structured variable isn't worth writing.

A language that doesn't affect the way you think about programming, is not worth knowing.

Wherever there is modularity there is the potential for misunderstanding: Hiding information implies a need to check communication.

Optimiziation hinders evolution.

A good system can't have a weak command language.

To understand a program you must become both the machine and the program.

Perhaps if we wrote programs from childhood on, as adults we'd be able to read them.

One can only display complex information in the mind. Like seeing, movement or flow or alteration of view is more important than the static picture, no matter how lovely.

There will always be things we wish to say in our programs that in all known languages can only be said poorly.

Once you understand how to write a program get someone else to write it.

Around computers it is difficult to find the correct unit of time to measure progress. Some cathedrals took a century to complete. Can you imagine the grandeur and scope of a program that would take as long?

For systems, the analogue of a face-lift is to add to the control graph an edge that creates a cycle, not just an additional node.

In programming, everything we do is a special case of something more general - and often we know it too quickly.

Simplicity does not precede complexity, but follows it.

Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis.

The 11th commandment was "Thou Shalt Compute" or "Thou Shalt Not Compute" - I forget which.

The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information.

Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers.

The use of a program to prove the 4-color theorem will not change mathematics - it merely demonstrates that the theorem, a challenge for a century, is probably not important to mathematics.

The most important computer is the one that rages in our skulls and ever seeks that satisfactory external emulator. The standardization of real computers would be a disaster - and so it probably won't happen.

Structured Programming supports the law of the excluded muddle.

Re graphics: A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures.

There are two ways to write error-free programs; only the third one works.

Some programming languages manage to absorbe change, but withstand progress.

You can measure a programmer's perspective by noting his attitude on the continuing vitality of FORTRAN.

In software systems it is often the early bird that makes the worm.

Sometimes I think the only universal in the computing field is the fetch-execute-cycle.

The goal of computation is the emulation of our synthetic abilities, not the understanding of our analytic ones.

Like punning, programming is a play on words.

As Will Rogers would have said, "There is no such thing as a free variable."

The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book on anything for the layman.

Giving up on assembly language was the apple in our Garden of Eden: Languages whose use squanders machine cycles are sinful. The LISP machine now permits LISP programmers to abandon bra and fig-leaf.

When we understand knowledge-based systems, it will be as before - except our finger-tips will have been singed.

Bringing computers into the home won't change either one, but may revitalize the corner saloon.

Systems have sub-systems and sub-systems have sub-systems and so on ad finitum - which is why we're always starting over.

So many good ideas are never heard from again once they embark in a voyage on the semantic gulf.

Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.

A LISP programmer knows the value of everything, but the cost of nothing.

Software is under a constant tension. Being symbolic it is arbitrarily perfectible; but also it is arbitrarily changeable.

It is easier to change the specification to fit the program than vice versa.

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

In English every word can be verbed. Would that it were so in our programming languages.

Dana Scott is the Church of the Lattice-Way Saints.

In programming, as in everything else, to be in error is to be reborn.

In computing, invariants are ephemeral.

When we write programs that "learn", it turns out we do and they don't.

Often it is means that justify ends: Goals advance technique and technique survives even when goal structures crumble.

Make no mistake about it: Computers process numbers - not symbols. We measure our understanding (and control) by the extent to which we can arithmetize an activity.

Making something variable is easy. Controlling duration of constancy is the trick.

Think of all the psychic energy expended in seeking a fundamental distinction between "algorithm" and "program".

If we believe in data structures, we must believe in independent (hence simultaneous) processing. For why else would we collect items within a structure? Why do we tolerate languages that give us the one without the other?

In a 5 year period we get one superb programming language. Only we can't control when the 5 year period will begin.

Over the centuries the Indians developed sign language for communicating phenomena of interest. Programmers from different tribes (FORTRAN, LISP, ALGOL, SNOBOL, etc.) could use one that doesn't require them to carry a blackboard on their ponies.

Documentation is like term insurance: It satisfies because almost no one who subscribes to it depends on its benefits.

An adequate bootstrap is a contradiction in terms.

It is not a language's weaknesses but its strengths that control the gradient of its change: Alas, a language never escapes its embryonic sac.

It is possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as soap bubble?

Because of its vitality, the computing field is always in desperate need of new cliches: Banality soothes our nerves.

It is the user who should parametrize procedures, not their creators.

The cybernetic exchange between man, computer and algorithm is like a game of musical chairs: The frantic search for balance always leaves one of the three standing ill at ease.

If your computer speaks English it was probably made in Japan.

A year spent in artificial intelligence is enough to make one believe in God.

Prolonged contact with the computer turns mathematicians into clerks and vice versa.

In computing, turning the obvious into the useful is a living definition of the word "frustration".

We are on the verge: Today our program proved Fermat's next-to-last theorem!

What is the difference between a Turing machine and the modern computer? It's the same as that between Hillary's ascent of Everest and the establishment of a Hilton hotel on its peak.

Motto for a research laboratory: What we work on today, others will first think of tomorrow.

Though the Chinese should adore APL, it's FORTRAN they put their money on.

We kid ourselves if we think that the radio of procedure to data in an active data-base system can be made arbitrarily small or even kept small.

We have the mini and the micro computer. In what semantic niche would the pico computer fall?

It is not the computer's fault that Maxwell's equations are not adequate to design the electric motor.

One does not learn computing by using a hand calculator, but one can forget arithmetic.

Computation has made the tree flower.

The computer reminds one of Lon Chaney - it is the machine of a thousand faces.

The computer is the ultimate polluter. Its feces are indistinguishable from the food it produces.

When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.

Interfaces keep things tidy, but don't accelerate growth: Functions do.

Don't have good ideas if you aren't willing to be responsible for them.

Computers don't introduce order anywhere as much as they expose opportunities.

When a professor insists computer science is X but not Y, have compassion for his graduate students.

In computing, the mean time to failure keeps getting shorter.

In man-machine symbiosis, it is man who must adjust: The machines can't.

We will never run out of things to program as long as there is a single program around.

Dealing with failure is easy: Work hard to improve: Success is also easy to handle: You've solved the wrong problem. Work hard to improve.

One can't proceed from the informal to the formal by formal means.

Purely applicative languages are poorly applicable.

The proof of a system's value is its existence.

You can't communicate complexity, only an awareness of it.

It's difficult to extract sense from strings, but they're the only communication coin we can count on.

The debate rages on: Is PL/I Bachtrian or Dromedary?

Whenever two programmers meet to criticize their programs, both are silent.

Think of it! With VLSI we can pack 100 ENIACs in 1 sq.cm.

Editing is a rewording activity.

Why did the Roman Empire collapse? What is the Latin for office automation?

Computer Science is embarrassed by the computer.

The only constructive theory connecting neuroscience and psychology will arise from the study of software.

Within a computer natural language is unnatural.

Most people find the concept of programming obvious, but the doing impossible.

You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program.

It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organizing thoughts, devoting attention to detail and learning to be self-critical?

If you can imagine a society in which the computer-robot is the only menial, you can imagine anything.

Programming is an unnatural act.

Adapting old programs to fit new machines usually means adapting new machines to behave like old ones.

In seeking the unattainable, simplicity only gets in the way.

If there are epigrams, there must be meta-epigrams.

Epigrams are interfaces across which appreciation and insight flow.

Epigrams parametrize auras.

Epigrams are macros, since they are executed at read time.

Epigrams crystallize incongruities.

Epigrams retrieve deep semantics from a data base that is all procedure.

Epigrams scorn detail and make a point: They are a superb high-level documentation.

Epigrams are more like vitamins than protein.

Epigrams have extremely low entropy.

The last epigram? Neither eat nor drink them, snuff epigrams.