I remember from the very early days in my career.
I was a consultant, and the client had a big demo of the solution we had been working on. The audience would be global.
Prior to the demo, we only had one feature planned to be shown. It worked standalone. However, the real value of the feature was when it would be applied in a loop over a collection.
Hence, the client requested a last-minute change prior to the demo. This was literally a few minutes before the demo. The presumption was that if the feature worked for a single item, then just iterating over a collection would not be so detrimental.
Whereas reality had other plans. I was suggesting we demo just the feature, not the iteration over the collection. The iteration logic was not tested, and who knows what would happen during the demo if we presented such an untested solution. The client asked, “Will it crash?” And there was very little probability that the solution would crash. So the client insisted on the change despite the risks.
Working Code
Show ALast-minute change
for i = 0 to n-1 {
Show A
}As you may imagine, the demo bombed. Due to a last-minute change, the implementor forgot to pick an element from the collection, so it displayed a constant value.
So if the expectation was that 3 different items would be displayed, 3 items were indeed displayed, but they were just the first element being displayed 3 times.
Big learning: However small the change, don’t do it just before a demo. Demo what you are confident of.
It would have been much better if we had said that the demo was only for a single item, and the handling of a collection of items was still in the works.