Recently I was working on a design to help a user with installing a complicated application. In the way this thing was built, the user had to, at first installation, update a settings file. The settings file was in the form of json (JavaScript Object Notation) which is just a way to describe an object in the form of classes, properties, etc.
I have no idea why this was done, but my gut tells me it was a quick duct tape solution to a problem that no one had time to code for.
This type of thing is often done in software and feels like the quick fix one loves to apply…however it introduces a pattern that no one wants to apply. It adds a point of failure.
A point of failure is any place where things can go wrong, either because of some flaw in work or just real world use. When we add a required or optional user action, the point of failure creates a mess. To understand why, let’s consider the case I had and why a point of failure is a lot worse than one thinks.
In my case, the user needs to make a change to a configuration setting, ONCE only and before the thing is initially used.
That requirement already introduces a point of failure with potential bad outcomes. To see this, we will use a flow diagram;
