Sunday, 17 January 2010

Failsafe application development: a visual as to how (errors)


I'm doing a series on failsafe application develoment this weekend it seems, driven by pure passion and inspiration. My first post described the what, my second explained the why, and this one's on the how

Having some insight into or experience with programming will help, but I hope you can also grasp the concept if you just think geeks are cute
As an example, I will take an easy creditcard transaction

First, I have to get two paradigms out of the way: the combine conditions as much as you can paradigm, and the combine functions as much as you can paradigm. They're both deadly wrong



The combine conditions as much as you can paradigm is decades old, and served for memory optimisation back in the '80-s. Visualised, it did this:

IF CARD VALID
AND AUTHORISATION OKAY
AND ENOUGH CREDIT THEN
-->TRANSACTION SUCCESSFUL
ELSE
-->ERROR: SOMETHING WENT WRONG

This combines all conditions to one big condition: this was the start of what I call target-driven programming that leaves you empty-handed when something goes wrong. Because all you know is that one of those conditions failed to be met. Understandable why this once was started, it is unacceptable that this is still happening
The combine functions as much as you can paradigm, related to functional programming, is a decade or so old, and was born out of nerdness in the 90's AFAIC. Visualised, it did this:

IF CARD(AUTHORISATION(CREDIT)) THEN
-->TRANSACTION SUCCESSFUL
ELSE
-->ERROR: SOMETHING WENT WRONG

This combines all functions to one big condition: it's the same thing as above, but allows for greater complexity because it's not just a simple condition you check, it's an entire function. I think this once started to save whitespace, no idea really. Anyway, no reason to continue that either

Same predicament here: if the sum of all elements doesn't add up, you'll have to inspect each element to find out wich one actually caused the error. And that means re-evaluating conditions in IT, and usually it's too late for that

This is how that would look if you'd use the "tick-off-the-box" paradigm:

IF NOT CARD VALID THEN
-->ERROR: CARD INVALID
EXIT

IF NOT AUTHORISATION OKAY THEN
-->ERROR: AUTHORISATION NOT OKAY
EXIT

IF NOT ENOUGH CREDIT THEN
-->ERROR: NOT ENOUGH CREDIT
EXIT

Legible, simple, easy-to-understand. And extremely user-friendly. Any objections?

0 reacties:

Post a Comment

Thank you for sharing your thoughts! Copy your comment before signing in...