New and Improved Software Error Continuum

On about the first day of Computer Programming 101, we were taught about a continuum of error types that exist in software.  This continuum spanned a range of error types on a spectrum from “least problematic” to “most problematic.”   That continuum is as follows:

Classic Error Continuum:

  1. Compilation/Syntax Errors
  2. Runtime Exceptions
  3. Logic Errors

I’ve written a previous post about the importance of taking every opportunity to design code that you write in such a way that pushes possible errors towards the less problematic end of the continuum, towards the lowest numbered type possible.

I’d like to revise that continuum to bring it a forward a bit, such that it accounts for more modern testing practices which were omitted due to their near nonexistence at the time I attended college.

New And Improved Error Continuum:

  1. Compilation/Syntax Errors (best)
  2. Automated Test Failures
    1. Unit Test Failures
    2. Integration and U/I Test Failures
  3. Runtime Exceptions
    1. Exceptions which occur close to their cause
    2. Exceptions which occur distant from their cause
  4. Logic Errors (worst)

It is unfortunately common for developers and teams to unwittingly design their code in such a way that pushes likely errors in the worst direction rather than in the best direction.

If each developer on your team makes hundreds or even thousands of decisions in code over the course of months or years of an application’s lifespan, then the necessity of preserving and validating and making explicit each little piece of developer intent is of paramount importance.

The weakest styles of software validation lead to a high likelihood that a project will be prone to the worst type of errors, Logic Errors (#4), which effectively require that every developer maintain constantly in their mind ever piece of every previous developer’s past intent, always and forever, to avoid introducing any defects in any new work that they produce.  This is of course impossible to achieve, and such software will become littered with a much greater rate of defects than is absolutely necessary.  (I’m looking at you, Anemic Domain Model.)

The sooner you acknowledge that you cannot hold an entire application’s code in your head, the sooner you can begin to account for this fact in the design of your code.  I know a lot of renowned Computer Scientists have long since beaten me to the punch on this realization, but alas I cannot locate their quotations on this matter, so for now I’m left with just this, my own paraphrasing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s