Fail Fast and User Interaction

Dave Kipfer writes:

I was browsing Martin Fowler's web-site and ran across [your Fail Fast article]. You have made your point well, however one thing comes to mind from my own experience effectively being an end-user of some products where I work.

What I have found is that sometimes products or systems fail too fast. Referring to your example of the properties file, let's say that there are many properties expected in that file. Let's also say that the user has omitted several of these properties. If I understand your philosophy correctly, the user will suffer as many failures with the software as there are missing properties, only knowing of them when the previous one is corrected. It seems to me that there needs to be some middle-ground, where failure conditions need to somehow be aggregated to minimize going through the process of fixing them, and ultimately minimize frustration.

Do you have any thoughts on that?

I responded:

You raise a good point, one I should have addressed in the article. In that example, I was imagining that the properties file was configured by developers before delivery and then not edited thereafter. This is common in server-side applications. If only developers touch the properties file, then it's okay to fail fast in the way I recommend.

If a property file is meant to be user-editable, then I still advocate failing fast, but I would provide a nicer UI around it. Either I would create a scanner that checks for problems and reports them all at once or (even better) provide a user tool that guarantees file consistency. I would leave the fail-fast checks in as a safeguard against bugs in the scanner or tool.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.