Make a wish and (probably) it will become true.

The only problem is that the person who is making the wish does not realize that his wish (may not) come true and accept his own thoughts as facts.

----
Or ... how about "decide that something ''has'' occurred, and it probably will."

Occasionally, it already did.

I have too much anecdotal (first-hand) evidence to dismiss this as nonsense.

----
Another example, via BuildForTheFuture - "sure, we're selling at a loss, but we'll make it up in volume."  Scary part is, I ''knew'' and worked with several dot-coms that literally ran off this philosophy.

----
"Wishful Thinking" has also a positive meaning. It is a general technique for abstract thinking:

Accepting that a component (class, module, ...) works without having seen its implementation, maybe even without ''having'' an implementation.

This is taught very intensively in "Structure and Interpretation of Computer Programs" (http://www.swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/).

Two examples from the video lectures follow.

----
"Wishful Thinking" is a very powerful programming practice:

Before implementing a component you write some of the code that ''actually uses'' it.  This way you discover what functions with what parameters you really need, which leads to a very good interface.  You will also have some good test code for your component.

The idea is based on the fact that an interface's purpose is to simplify the code that ''uses'' the component, not to simplify the code that ''implements'' it.

----
"Wishful Thinking" is a good way to think about recursion:

When seeing a recursive call, you should not think about the code being executed on each sub call.  Instead, just imagine that the sub call does its job correctly.

Thus, you prove the correctness of the function by assuming that it is correct (on simpler input).  This is some positive kind of self-fulfilling prophecy.

Of course you still have to check for trivial cases and need to assure that the recursive call handles a simpler case of your problem.  But those are minor issues.  The hardest part is to understand the recursive calls.

Without the technique of wishful thinking, you can't handle problems like "Towers of Hanoi", let alone more complicated ones.

----
https://news.ycombinator.com/item?id=5765270

Also kind of related - programming by "wishful thinking". You first lay out the flow of the program as calls to high level functions which don't yet exist, and then go back and fill in the functions as you can. The first few SICP video lectures are all about this style, and I found the idea simple but very useful to avoid trying to hold too much of a problem in your head at once.

Yes, exactly. By writing pseudocode, I end up writing business code rather than implementation code, which inherently assumes the a high-level interface to the nitty-gritty details. This leads to an approach where the idea is expressed at a high level first, rather than getting stuck in the implementation details of some small piece of the problem.

Code is a planning language, so rather than boxes and noodles or pseudocode, I tend to sketch out my plans in code itself. In SICP this is called "design by wishful thinking": you pretend that you already have a library of primitives that do the nitty-gritty work and write the high-level bits of your program using those primitives. Then, you go back and implement the primitives.

Indeed, the "design by wishful thinking" was a real eye opener for me. It is one of my favourite parts of SICP. It can also be explained as way to postpone decision you can't clearly make right now. First, you pretend to have made the decision, and later on you implement the decision "you wish you had made".

----

Also apropos design/programming by WishfulThinking: 

	 :	''It is the user who should parameterize procedures, not their creators.'' - AlanJPerlis, Epigram #76 (EpigramsInProgramming)

----
See also: WishfulThinkingCausesBadLuck