/* ---- Google Analytics Code Below */

Wednesday, December 04, 2019

The Further Value of Demo Data

At first I didn't understand the claim being made here, but after I understood it,  remembered we had done sometime similar for a manufacturing application,  but this takes it further yet.   This still requires that the program you have will likely need to be updated as the system evolves.   And sometimes that can be time consuming too, so you are betting on that as well.   Still a good idea to consider, and a kind of collaboration with the users and decision makers, forcing them into earlier involvement.

Demo Data as Code
Automation helps collaboration.   By Thomas A. Limoncelli

Engineers are often asked to generate demo data for various reasons. It may seem like this one-time task can be done manually and forgotten. Automating the process, however, has many benefits, and supports the inevitable need for iteration, collaboration, and future updates. When data is treated as code, you can leverage techniques from modern software engineering practices.

Many years ago I was at a company that needed to produce a demo version of its software. The demo would essentially be the company's software preloaded with fictional data. Salespeople would follow a script that would walk the customer through the features of the product. The script involved finding various problems and resolving them with the ease that only this product could provide.

Marketing would create the script, and engineering would create a dataset that would support the story.

Using live customer data in the demo was not an option because that would be a privacy violation. Even so, no one customer dataset could support the entire demo script.

This project had many red flags. Engineers were expected to work on it "in their spare time." That misunderstands and devalues engineering work. When nontechnical managers don't understand something, they often assume it is easy to do and, thus, obviously shouldn't take very long.

More worrisome was the fact that this "spare time" theory was supported by the incorrect assumption that the project was a one-time thing. That is, the data would be generated once and be perfect on the first try; the engineers could then wash their hands of it and return to their regularly scheduled work.

This assumption was intended to be a compliment to the engineers, but, "Oh, please, this will just take an afternoon!" is not a tenet of good project management.

I don't know about you, but I've never produced something for marketing without being asked for at least one revision or adjustment. This is a creative collaboration between two groups of people. Any such project requires many iterations and experiments before the results are good or good enough.
  ... "

No comments: