The happy path

Always follow the happy path when demoing, unless you want to find bugs and issues.

When demoing my software, I'm like: Here's the app, see if you understand.
I'm curious how the user will use my software and I'm also curious if they will get stuck somewhere so that I know what needs to be improved. And I'm also very confident about the software I have written.
But what happens? The user finds a bug, the softweare crashes or there's some other issue.
The user might do something I have not thought about, or that I have never done myself, or take different steps then I do.
This has happened so many times now, so there must be some kind of rule. Demoing the software must be the fastest way to find bugs.

I do like to find bugs, and I practive "defensive" programming so that bugs are detected early.
But bugs and errors does not make an impressive demo.
That's why you should always take the same steps while demoing. Don't let the user have the device, you control the device, and follow a script, that shows the software capabilites. This script is often called the "happy path".

Test the happy path

The happy path should be walked every time there is a new release. And if possible, it should be tested automatically. So when you demo the software, it should always give the same results.

Software development is like hiking

Some phenomens in softweare development can be explanined by thinking of software development as hiking. The happy path is the trail you have walked many times before. Not following the happy path is like going off road.

Written by May 2, 2020.

Follow me via RSS:   RSS https://z├Ą (copy to feed-reader)
or Github:   Github