What to do when asked to fake or fudge a demo to the customer? Any hints on pushing back?

Consider having an unstable, incomplete, and not completely tested system. Then consider needing to demo it to the customer. The system being unstable, incomplete and not completely tested because an external supplier was not delivering what they promised and when they did deliver it is really bad code.

After pushing back, and pushing back on demoing the system to the customer, the customer finally insists that they must see a demo of the system.

What do you do if your boss comes up to you and tells you to just fudge and fake the demo?

This recently happened to a friend and I was completely at a loss at to what he should do. My first reaction would have been to push back and say no way, "you're just postponing the inevitable pain!" Not to mention the fact that it is not ethical!

I was wondering what the StackOverflowers would do, or have done?

BTW My friend has now worked for six weeks straight, including weekends, without a day off from 8 in the morning to 9 at night!

And colleagues of his are being told that they must work next Saturday and Sunday. Being told and not asked! 8-O

TIA

cheers,

Rob

Edit: I forgot to add that the project is supposed to be run in an agile manner using Scrum and sprints!

Edit: Well, the first demo didn't even install it was that bad. A second demo didn't work and now the third drop actually works. After a fashion. Trouble is it takes over ninety seconds just to get the home page to load! Heaven knows what their search functionality is going to be like!

What do you do when your boss is in denial about how bad the code is? Probably because he was heavily involved in the selection process for the company.

From stackoverflow

• That is a really awful situation. I am fortunate enough to have never been asked to do anything like this, so I really can't weigh in with my own personal experiences.

  I'm going to have to say my reaction is the same as your initial reaction. He is clearly not working for a good company as he is forced to work weekend after weekend. Not only that but he is constantly being asked to put his own moral reservations aside for a management which is clearly unethical. Beh!

  I understand that it's hardly as easy as "just walking away" but in the long term this is undoubtedly for the better.

• I have the same reaction as @Marcus -- time to start working on the ol' resume.

  On the other hand, I firmly believe in releasing early and often and only releasing working code. Perhaps, he could work to change how the code is developed so that it is done in a more humane manner and one that allows the customer much better feedback, sooner. This would allow problems like this can be discovered earlier, before you get into the death march.

  Check out stuff on agile methods at the Agile Alliance.

  Rob Wells : This is *supposed* to be an agile project!

  tvanfosson : Apparently they didn't read the Agile Manifesto.

• It's your friend's boss prerrogative to ask from employees to do as he likes, and his is also the prerrogative to show deceptive demos.

  On the other hand it's your friend's prerrogative to tell the boss what he thinks about that and first try to convince him not to, second ask not to participate in it and third just quit and look for work in another place.

  I feel that the first two alternatives your friend has won't work given the type of boss he's likely to have, so...

  Rob Wells : @Vinko, cheers and thanks for the pragmatic approach! (-:

  MusiGenesis : I know this is the real world, but in theory at least a boss does not have the right to order his/her employees to lie outright.

• This is only the least-bad of the alternatives, but: do the faked demo, but tell the client that it is faked. Not literally "faked", of course, but tell them that it does not represent fully-functional software. Everybody knows what a demo is.

  DO NOT lie to the customer. Even if you don't care about ethics, you should care about yourself, and sometimes low-level employees can become scapegoats in a situation where a client has documented evidence of fraudulent behavior on the part of your company.

  Rob Wells : @MusiGenesis Ooh. Didn't think of that one! 1) take what is there, 2) be upfront about what isn't, and 3) explain how you're simulating those parts of the system. I'll pass that on to K.

  Vinko Vrsalovic : I fully agree with this approach. But I'd start looking for a job elsewhere nonetheless.

  MusiGenesis : @Vinko: if the six straight weeks of work didn't chase this guy off, nothing will.

  Vinko Vrsalovic : Maybe a chainsaw wielding boss?

• I think it was Martin Fowler who said it first: "Change your organization or change your organization."

  Can you find out what the boss's need is behind wanting to fake the demo? Can you help him fullfil that need in an ethical way, at the same time mitigating the risk that the customer finds out about being treated unethically? Can you help him improve your process so that you can work at a sustainable pace, for example by adopting an iterative approach?

  Failing that, the only alternative I see is to run. Quickly.

• The main point is to realize that it is just a demo, and not a "Come and play with the system that is almost ready".

  Demo's should be flashy and visually finished where functionality is working, and rudimentary where it doesn't.

  That way when the system goes boom in an unfinished area, you can smile limply and say, "Obviously this still needs a bit of work".

  Under no circumstances try to put lipstick on a chicken and style up somnething that doesn't work, because then the customer will think that the part is almost done, when it is nothing but a facade.

  That being said, if you really need to give the appearance of better progress than you actually have, you need to control the agenda.

  Prepare the demonstration like a script. Make sure the program can complete the script, even if that means ignoring the actual input from a search field and hardcoding the data layer to always return the same 5 entries no matter what the input.

  If the customer asks to see something not scripted, be sure to head off the customer with a "Thats really insightful input; we will come back to that after completing the demonstration", and make damn sure the demonstration takes 10 minutes longer than the agenda allows for, so people will either have forgotten their request or have to go.

  Oh,

  and pray.

• Depends what kind of "fake and fudge".

  As an example, I once worked on a platform that sat on a mobile phone and ran games written for the platform.

  At the early stages of development, we "restricted" demos all the time. We'd get games from the game developer, and want to demo the newest, flashiest games if possible. But the newest flashiest games were the least well-tested on our platform, so maybe if you finished the level it crashed, or we had to sneakily rip out a bunch of textures to fit it all in memory, or it only worked if you rebooted the phone right before running it. So the demo was "supervised", meaning you don't let the customer just walk off with it. You either drive it yourself, or else you keep an eye on them, and you stop them going outside the safe zone of operation.

  It's slightly dishonest, but I don't think it's unethical -- if the customer asked then you'd admit that there are still some undiagnosed bugs in the game/platform/both. But prior to first release, customers don't usually care about whether things work perfectly yet: they know that they don't, because if they did you'd have released already. Letting the demo crash gives a bad impression, because it implies you have undiscovered bugs you can't work around. Bugs you know about but haven't fixed yet aren't so much of a threat to the project, so don't let the customer see them unless they've signed something that gives them a right to view your blocking issues list.

  As against that, compiling up a native-for-that-phone version of the game, showing it to the customer, and claiming it was running on our platform when it wasn't, would have been fraudulent. That's unethical and potentially illegal. So we didn't do that (and anyway, for at least one game the native Symbian versions for the demo handsets actually ran slower than on our platform. Heh.)

  If all else fails, and you have to completely fake up a demo by hacking together a bunch of code yourself that looks like the real thing but doesn't actually work at all, tell the customer it's a user interface prototype, not a product build. Sometimes the reason they must see a demo is because they want to know how the product will handle, not because they want proof that the product works yet. Prototypes are usually a waste of time, and it's better to build the real product iteratively, but if they want to see a demo just so they can comment on the colour scheme, then show them the colour scheme on a bunch of faked-up, non-working windows.

  If you're just being asked to produce the demo, not to show it to the customer, then personally I'd go on record that I thought it was costing time that should have been spent on the real product, but leave it to someone else to make the decision whether to lie to the customer. If the sales guys are determined to lie then you can't stop them just by refusing to produce the demo in the first place - they'll only tell a different lie. Usually you can't fix everyone else's ethics to match your own, all you can practically do is leave.

  Being overworked is IMO a completely independent issue from faking demos. Ed Yourdon's "Death March" is a really interesting handbook for dealing with that situation, and the number 2 piece of advice (after "don't get into them unless you really want to") is knowing when and how to get out. The similarity with the fake demos is that sometimes you can't refuse just to do the bit you don't want to, you have to quite the job.

  Rob Wells : Totally agree. But from what I understand this request was to not say to the customer that it wasn't a true demo

• I forgot to add that the project is supposed to be run in an agile manner using Scrum and sprints!

  If its agile and they are doing sprints then the demos should be happening at the end of each sprint. Clearly this isn't so.

  This is an old style Death March tell your friend to start working his resume and his professional network and get out of there!

  JeffH : +1 for calling it a Death March. @OP - Have your friend get Edward Yourdon's book of the same name, 2nd ed.

• Sounds like there hasn't been enough status reporting going on, if it was known that the external supplier was late and when the deliver was received it wasn't good enough then this shouldn't be a surprise.

  I'd do the demo and make sure that I had clear plans in place to address all of the problems which could also be shared with th customer.

• SCRUM clearly tells that you cut in features, and DONT add time if not finnished all sprint log items on time. So both the customer AND the client has no clue of what they are doing.

  I would leave the company. IF your pal demo the system, the customer will believe the program is finished, so NOW he has to sit day AND night to deliver something the customer believe allready is done. Its a lose-lose-situation.

• I would be upfront with the customer about what parts of the demo are really working features and which parts are fake. Faking and not telling them is not only unethical, it also leads to unreasonable expectations. They're going to be making plans and decisions for their own company based on what you tell them you can do. They're also going to expect you to be able to deliver the software you demoed, on the date you say it will be ready. I'm sure your customer will understand that a vendor didn't deliver to you on time. We've all had that happen, so just be honest with them.

• I would make a power point presentation for the customer, including screen shots. Walk the customer through how the system "will work at completion" and state that much of the major functionality is still being worked on.