Sunday, 17 January 2010

Failsafe application development: a parable as to why

If you haven't got a clue about IT and applications, that will have changed after reading this. This post is about every day life, family, management, and control. It's a follow-up on my last post where I introduce failsafe application development - my way

In your life, you are the one that is aware of everything that's occurring around you. That doesn't mean you understand it, but it is enough that you can narrate it afterwards. With camera-equipped mobile phones everywhere, you can even objectively replay what happened - how's that for awesomeness
So, if anything out of the ordinary happens, you're there, you notice it
That doesn't mean you know why that happens because you don't always know the circumstances. If
you're run over by a truck, you usually do. But if your kids bring home a bad school report, it affects your life but it's your kids that have more knowledge than you about what led to that. Makes you wish you'd been there sometimes

Not to prevent things, but just to know what happened, so knowledge about it will help to fix it

Your manager has a similar kind of challenge: he's responsible for what his employees do and achieve, but he can't be there all the time. Sometimes, employees make a mess of things, intentionally or unintentionally. The manager is stuck with the results, and wishes he'd been there more often so he could have seen this coming
Not to prevent things, but just to know what happened, so knowledge about it will help to fix it

Banks, management, credit crisis, families, mortgages: you know where I'm going with this. If only we'd been there, and had known, we could have prevented it. But if only we'd know the circumstances now, we could learn from it. Because:

The knowledge of the circumstances that led to this occassion could help us fix the problem

Here's how an application works: it runs programs. The programs run modules. The modules run functions. The functions interact with other functions: they exchange information. When a program's finished, there's a result, and everything that happened before that, has gone from memory
That's even worse than everyday life: you can't ask your kids or employees what happened because there's no memory of it. That's why in IT there is the need to reproduce errors: you want to replay the event because that's the only way to reproduce the error. If only you'd been there with your camera-equipped mobile phone...

With today's applications, reproduction is simply impossible. Applications interact with others, there are thousands of concurrent users, even unknown customers on the outside, and in a few years from now, part of it is in the Cloud as well

So, you want to be there. All the time. You want to run along every single application, program, module and function. Because you can't afford to miss a thing.
And The Object enables you to do so

My next post will give a few visuals about what it all means, going into detail

1 reacties:

Randy McClure said...


Another good post. Good analogies on how to catch errors that applies to any programming language and application. I am working with several expert systems, one of them created 10 years ago, and most of the on-going work is gracefully handling error conditions.

Post a Comment

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