I was recently reading Wikpedia's list of Anti-Patterns and noticed that this was included:
Smoke and mirrors: Demonstrating how unimplemented functions will appear
Why is this a bad thing to do? The only thing I can see is that if you never actually get around to implementing said function. And what if the function is in the formal spec, "guaranteed" to be completed? Would it still be bad to do in order to show potential clients what they'll be capable of?
To learn why smoke and mirrors would be an antipattern, take a look at the Smoke and Mirrors Wikipedia entry. From the article:
Smoke and mirrors is a metaphor for a deceptive, fraudulent or insubstantial explanation or description. The source of the name is based on magicians' illusions, where magicians make objects appear or disappear by extending or retracting mirrors amid a confusing burst of smoke. The expression may have a connotation of virtuosity or cleverness in carrying out such a deception.
In the field of computer programming, it is used to describe a program or functionality that does not yet exist, but appears as though it does (cf. vaporware). This is often done to demonstrate what a resulting project will function/look like after the code is complete — at a trade show, for example.
More generally, "smoke and mirrors" may refer to any sort of presentation by which the audience is intended to be deceived, such as an attempt to fool a prospective client into thinking that one has capabilities necessary to deliver a product in question.
Often times, smoke and mirrors are used to impress management or customers with a demo in order to get/keep funding, but there is no real code underneath. This works for a time, but, ultimately results in other anti-patterns (spaghetti code, the blob, etc) in order to try to get something real once it is actually asked for.
Projects that begin as Smoke and Mirrors tend to end horribly. Like a relationship, if you develop your code on lies, everything will fall apart in the end.
Smoke and mirrors seems different than a mock-up.
Smoke and mirrors would be if implementing something like a calculator you code all the methods for add, subtract, multiply and divide, but the more advanced functions all return random, appearing to do the job. Management oohs and aahs at the long string of digits.
While a number of answers have hinted at (what seems to me) the real problem, none has really given it directly.
The real reason "smoke and mirrors" is an anti-pattern is that it's confusing the distinction between a prototype and a finished product. Creating a prototype is perfectly fine. One of the major problems that many (most?) of us have run into is managers saying something like "well, that seems to work well enough, let's ship it."
Creating a prototype is usually a good thing -- but you must always be extremely careful both internally and (especially) to the outside world to be clear about the fact that it is a prototype, not a finished product. Management generally wants to believe that the prototype is a finished product (or at least can form the basis of one) anyway. Encouraging such a belief is a really bad thing.
Because all too often, it's 90% marketing, 10% management, and 0% development.
Under-promise, over-deliver. Not the other way around.
If you follow the link for Smoke and Mirrors you'll see this snippet:
In the field of computer programming, it is used to describe a program or functionality that does not yet exist, but appears as though it does (cf. vaporware). This is often done to demonstrate what a resulting project will function/look like after the code is complete — at a trade show, for example.
This is dangerous because in our world, ANYTHING can change.
