Quotes

General

Point of view is worth 80 IQ points.   [Alan Kay]

Good judgement is the result of experience.
Experience is the result of bad judgement.   [Mark Twain]

Cleverness is serviceable for everything, sufficient for nothing.   [Henri-Frederic Amiel]

Start stupid, and evolve.   [Kent Beck]

The simplest explanation is probably the right explanation.   [Occam's Razor]

Yesterday's complexity is tomorrow's order. The complexity of molecular disorder gave way to the kinetic theory of gases and the three laws of thermodynamics.   [Steve Lukasik]

A system should always look like it was designed top-down (whether it was created top-down or bottom-up).

A designer knows he has achieved perfection NOT when there is nothing left to add, but when there is nothing left to take away.   [Antoine de Saint-Exupery]

A complex system that works is invariably found to have evolved from a simple system that works. A complex system designed from scratch never works and cannot be patched up to make it work.   [John Gall]

There was an important job to be done, and Everybody was asked to do it. Everybody was sure Somebody would do it. Anybody could have done it, but Nobody did it. Somebody got angry about that, because it was Everybody's job. Everybody thought Anybody could do it, but Nobody realized that Everybody wouldn't do it. It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done.

Programming

Computer time is extremely cheap compared to programmer time. It makes sense to let the computer locate our mistakes and otherwise pick up after us.   [Peter DeGrace and Leslie Hulet Stahl]

A five-to-one ratio between the shortest and longest implementations is quite typical, and usually the shorter programs are better.   [Peter DeGrace and Leslie Hulet Stahl]

I once spent days writing two pages of code that used a pair of stacks to traverse a complex data structure. When I finally viewed the problem the right way, a recursive program did the job in two dozen lines.   [Jon Bentley]

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.   [C.A.R. Hoare]

Problem Solving Hints and Wisdom

by Robert Harris

  1. Take time to examine and explore the problem thoroughly before setting out in search of a solution. Often, to understand the problem is to solve it.
  2. Breaking the problem into smaller parts will often make solving it much easier. Solve each part separately.
  3. The resources for problem solving are immense and ubiquitous.
  4. You can always do something.
  5. A problem is not a punishment; it is an opportunity to increase the happiness of the world, an opportunity to show how powerful you really are.
  6. The formulation of a problem determines the range of choices: the questions you ask determine the answers you receive.
  7. Be careful not to look for a solution until you understand the problem, and be careful not to select a solution until you have a whole range of choices.
  8. The initial statement of a problem often reflects a preconceived solution.
  9. A wide range of choices (ideas, possible solutions) allows you to choose the best from among many. A choice of one is not a choice.
  10. People work to implement their own ideas and solutions much more energetically than they work to implement others' ideas and solutions.
  11. Remember the critical importance of acceptance in solving problems. A solution that is technologically brilliant but sociologically stupid is not a good solution.
  12. When the goal state is clear but the present state is ambiguous, try working backwards.
  13. Procrastinators finish last.
  14. Denying a problem perpetuates it.
  15. Solve the problem that really exists, not just the symptoms of a problem, not the problem you already have a solution for, not the problem you wish existed, and not the problem someone else thinks exists.
  16. A maker follows a plan; a creator produces a plan.
  17. Creativity is the construction of somethings new out of somethings old, through effort and imagination.

Case study - assumption articulation

by Robert Harris

Let's say you are the manager of a factory that makes portable electric generators. Your product is largely bolted together at final assembly by workers using air wrenches. The wrenches, like those you hear screaming in auto repair shops, make a lot of noise, hurting the workers' hearing and job satisfaction. Your problem is, "How can we reduce the noise made by these air wrenches?"

Note that as with most problem statements, the problem as stated implies certain solutions. If you simply accepted the problem as stated, you would probably think of some possible alternatives like these:

But instead of this, you decide to do some assumption articulation. Here are some of the assumptions being made:
  1. Air wrenches are noisy.
  2. We must use air wrenches to put the parts together.
  3. People must use the air wrenches.
  4. We must use wrenches.
  5. The fastening must take place in this area or in this factory.
  6. Bolts must be used to hold the pieces together.
  7. The employees don't like the noise.
As you think about these assumptions, some new ideas come to you:
  1. Air wrenches are noisy. Are all air wrenches equally noisy? Can we buy a quieter brand? Is there a "silent air wrench" being sold?
  2. We must use air wrenches to put the parts together. Why not use manual wrenches, or electric wrenches, or hydraulic wrenches?
  3. People must use the air wrenches. Why not use robots? Can we use the wrenches less? Rotate employees so that each one uses the wrenches just a little each day.
  4. We must use wrenches. Why not use other tools? Nut drivers?
  5. The fastening must take place in this area of the factory. Why not move it outside? Subcontract it? Put it in a special soundproof room?
  6. Bolts must be used to hold the pieces together. Why not rivets? Spot welding? Adhesive? Screws? Clamps? Mold some of the pieces together so they need not be bolted or fastened at all?
  7. The employees don't like the noise. Get employees who like noise? Who don't hear it (like deaf people)? Give them ear muffs? Play loud music to mask the noise?

Note that ideas like robots, deaf employees, adhesive bonding and so on would not be suggested by the original form of the problem statement, which is based on several perhaps unnecessary assumptions. A little assumption articulation breaks our thinking out of these restraints and allows us to see some new possibilities.