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?
Subscribe to:
Post Comments (Atom)
0 reacties:
Post a Comment
Thank you for sharing your thoughts! Copy your comment before signing in...