Saturday, April 20, 2013

R is for Robustness

Stock Photography: Tank Picture. Image: 239332
© Photographer Stephanie Raines | Agency: Dreamstime.com

Robustness is a quality that saves your application from crashing and burning every time the unexpected happens.

And, believe me, in business software you should expect the unexpected.

Frequently.

Many of the things I have or will cover in this series will naturally lead to more robust applications. Things like defensive design stop your code being tripped up by unexpected data, and validation helps stop bad data appearing in the first place. Insulation and separation help break down a monster meal into bite sized chunks. Small chunks are easier to code and test, and to be confident they are working properly.

Even with all the above, your code will choke sometimes. It might not even be your fault. Servers crash. Network connections fail. What happens next depends on you.

Suppose your user is entering the final line of a fifty line purchase order when the system crashes. Good robust design will ensure that the user has lost as little work as possible if the worst happens. This means keeping track of what's been done up to the most recent point possible - in a way that it can be resumed later. In this example, you don't want to have to start off again at line one. You really want to find everything held safe at least up to line forty nine, leaving you to finish off what you were doing before the gremlins struck.

This is not rocket science. In fact, why only cater for system-generated gremlins? Users sometimes need to "crash out" of long and complicated tasks too. Forgot some of the details you needed to enter? Need to go and check something out half-way through? Phone rings and you really need to deal with it, which involves abandoning your transaction to do something else? Urgent need for the washroom? Allowing your users to leave a complicated task half finished, do something else, and come back later is a darned useful design feature. One that adds inherent robustness to your system.

This is all about bullet-proofing your application. I've more to say about bullet-proofing your business function too, which will come in a later post about Unhappy Paths.

9 comments:

  1. Returning your visit! Thanks for stopping by my blog! :)

    ReplyDelete
  2. Wow, I love learning new things!

    www.wearinglemon.blogspot.com

    ReplyDelete
  3. Your entire second blue font paragraph is excellent. You have a gift, Ian, for explaining things in layman's terms.

    Wonderful post :-)

    ReplyDelete
  4. Stephanie, you're welcome.

    Deb, that's my hope and the general idea :)

    Teresa, I like to think so. Now, if only I could get someone to pay me for it... :D

    ReplyDelete
  5. Excellent post and so easy to understand. Enjoyed very much.

    Yvonne.
    A to Z Ambassador.

    ReplyDelete
  6. I'm all for checkpoints! :D

    I was never a fan of the create temp file in memory, if exit requested, get input document path, write temp file in memory to document path.

    Duh, when crash happens, all your work is gone. What's wrong with getting input document path first and write to real file, not temporary file?

    Actually, this was something I'd run into before while beta testing a MUD client for someone. :)

    ReplyDelete
  7. Yvonne, thanks.

    Diane, temp files in memory is the lazy way out! Admittedly, the environment at my previous employer made checkpointing dead easy. We pretty much used the database as working memory - the syntax for handling database data was the same as for local variables and it was almost as efficient.

    ReplyDelete
    Replies
    1. It's usually those who have full control who become the most lazy programmers (still in college). Some of us more restricted folk have to develop inside a bubble while thinking outside the box. lol

      I use what I have, including experiences from my own failures.

      Delete
  8. It sounds like you have a very diverse background, and know a lot about computers. I know enough to just blog and write, so I think eventually I need to study up on the IT side of things.

    ReplyDelete

I love comments. Please feel free to join in the discussion.

I also try to respond to comments. I usually do so during the early evening (Pacific time) which may be many hours away from now!

So if you leave a comment and return some time later and I haven't responded yet, please don't think I'm ignoring you. I'm not. Honest.

Related Posts Plugin for WordPress, Blogger...