I’m not sure how I feel about doing demos for the ‘higher ups’ in the company. It seems that when we do a demo, we end up with a carefully crafted environment, that perhaps has a few hard coded values in place. It runs on a local developer’s machine with code that has not yet been put up for review. We can run through aspects of the feature and show what it can do, which is good in that it allows for feedback on things.
But there is a downside too.
Have we got accessibility in place? Is the code fully localized? Do we have a bunch of edge cases that we didn’t demo to clean up? What about those hard coded variables we put in place to make the demo work? What happens when that code gets off the developer’s machine and out into the wild? How will it perform under real life loads and stresses? There can be a LOT of work left to do on something that was shown in a demo, but does that really come through?
It seems like what can happen sometimes is we put our best foot forward in a demo, but we don’t show the things that are broken. We might mention some of the additional work that we need to do, but at the end of the day a picture is worth a thousand words. When someone sees a ‘working’ demo, and then hears about a few bullet points of additional work, what will they walk away from the meeting feeling?
‘Oh this is almost done’
Is it though?
I think a lot of demos leave people with a false impression of the state of the feature, and this can lead to problems. It can lead to schedule pressures – after all it looked almost ready last week so why isn’t it released yet? This can really get bad if people start talking to customers or even just internally ‘bragging’ about the feature.
I wish I had a magic solution, but I don’t. Well, I guess I do have one – don’t do them – but perhaps that is a bit extreme. I was just struck by the thought that this can be a problem, and I still need to think more about what can be done about it. Any thoughts? Have you ever seen this problem on teams you’ve worked with?