The x stages of software development

Some possible stages in the development of a system or a system developer…

  1. You are amazed the computer did what you told it, not what you wanted it to.
  2. You accept that any unexpected situation will kill your program, and there are lots of them
  3. You trap most unexpected things and throw up a message box, usually.
  4. You trap most unexpected things and stop gracefully, usually.
  5. You trap and log most unexpected things providing a non intrusive report/status
  6. You trap and recover successfully from many things, and log the rest.
  7. Nothing is unexpected, in a Zen like ‘if a system fails but no one notices, did it fail?’ way
  8. It moves to a SEP field (and here)

What did I miss?

Where do your systems normally end up?

What’s the highest you have reached?

Most of my quick and dirty stuff gets to a 4, production stuff gets to a 5 or 6 before skipping 7 and moving directly to 8.

And you?



3 Responses to “The x stages of software development”

  1. Keith Says:

    It is always somebody’s problem, the trick is getting the information to the person responsible for fixing it.

    The first line of defence is the person writing the code. I use a macro called ensure that works just like assert except it throws something that can be caught by const std::exception& instead of calling abort.

    When developing code, I tell my programmers to use it whenever in doubt. The upstream code wraps everything in try … catch and the testers can pinpoint the file, line, and condition that failed, then tell the programmers exactly where to look.

    C++ exception handling has termination semantics, like it or not. By the time the code goes into production, you should have preconditions that guarantee no exceptions will be thrown and that is the contract with your clients.

    Then nothing can go wrong … go wrong … go wrong in Westworld.

  2. Adam Vero Says:

    I think there is usually a stage of catching expected unexpected things (liek known unknowns), as you have not anticipated the full range of weird unexpectedness that can take place, before finally giving in to more catch-all approaches.

    In this context, “SEP” is of course “situation exceeded parameters” – if it is out of scope of the original brief or spece, this explains why it is somebody else’s problem, not yours.

  3. Simon Says:

    sorry I wasnt clearer, by SEP I meant that either you move on or the apps gets handed on to someone else to maintain.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: