Anti Pattern for November Smoke & Mirrors

Anti Pattern  for November Smoke & Mirrors

The title of the anti-pattern is Smoke & Mirrors AKA Marking Driven Dev elopement

 

The elaboration is read as: The Process of showing a demonstration to end-user without explaining that it is not production ready. The user’s exceptions are then based on the impossible promises made by the demo

http://deviq.com/smoke-and-mirrors

This link provides some further reading on the anti-pattern ( including an interesting photo). For your convenience I quote it as following:

The practice of showing a customer "smoke and mirrors" and then hoping the engineers or developers can build it has been around for as long as sales and marketing people have had jobs.  As long as what's being sold can realistically be delivered, this practice works great and ensures there is continued demand for new and improved products and services.  However, when the customer is told to expect the world, and typically within an unrealistic timeframe, that's a recipe for disaster.  Strive to under promise and over deliver (a.k.a. Deliver more than expected) wherever possible, and work closely with customers to develop the product so they see it grow from idea to finished product and aren't surprised at any point to learn that the full-featured demo they thought they saw was really just a bunch of wireframes and animations with nothing behind them.

 

The quote of the month is :

"Under promise; over deliver" - Tom Peters

 

In my decades of software development career, I realized that the some of those who practices this anti-pattern did so unintentionally. Due to lack of understanding on the complicity software development, when the developers show them a “work in progress” version of the system, they are so eager to show it to the end user with that understanding that the job is done and the developers can move on to another project. To them, “database design is put together some tables and put some columns  into each table” “programming effort” simply means write a few pieces of code and do some stuff”

Even if the system is as prototype stage, they would have no problem  to claim “the system does exactly what the end-user wants”.  The worse thing is that when the end-user complain the quality of the system, they pass on the blames to the developers who wrote the code and who told them it is not ready. I hope you are not working with those “architects” or “Project managers”. As for me, I have had a fair share of such experience in my career,  the way I handle them is in 2 stage, when I still hopeful in getting them to see the reality, I try my best to educate them, lead their perceptions towards reality.  When I realize that it is impossible to pull them out of their perception and they are determined to continue to lie to themselves, I will try to “state the fact as it is in writing, let them interpret the fact as they wish.”