The Problem with Software Quality

Software May 9th, 2007

For those who arn’t in the Software business, now’s probably a good time to go to another website. For those that are, I’m going to have a rant about Software Quality.

We are far too familiar with term “crash” than we should be. I pride myself on creating good quality software (and my job requires that I do since I work with safety critical systems). But the amount of crap out there is just phenomenal.

I was talking to a friend of mine who was about to roll out a software product at a customer site and I asked him:

“Is it well tested? Are you confident?”

He replied with:

“No and No”

Where I work we use DBC (Design By Contract) and find it immensely useful for finding defects. Basically we have functions like this:

bool AddItem(ListItem* item)
REQUIRE(item != NULL);
//add the item
ENSURE(list.size() > 0);
//return result;

If a REQUIRE or ENSURE is ever violated an onAssert__ function is called with a file name and line number.

This means that I can write a function and be damned sure that if it’s ever used in a way that wasn’t intended we’ll know straight away. See the problem is generally that a fault in code occurs, say something returns a 0, and then sometime later that value causes the application to crash. Unfortunately this may be 30 function calls later leaving you with a stack dump nowhere near your original problem. In my experience DBC allows you to catch the error when it occurs, and thus saves you time. If you use it, you’ll find that you get a DBC error and think “Thank god for DBC, that would have been a bitch to find otherwise”.

Anyway, I digress. I asked him whether he’d like our implementation of DBC and he said “nah, it’d be impossible to institute here anyway” and then he listed a two main reasons:

  • There is no emphasis on quality. In his line of work time to market is way more important than correctness and quality (which I find hard to fathom). So it doesn’t matter if you deliver a wrong product thats full of bugs, just so long as you’ve delivered something.
  • There is general apathy for quality in the workplace. People don’t want to improve things. They’re happy hacking away and since there is no requirement from above, why would they want to change?

Why don’t people want to improve the quality of their code? Because:

quality == boredom.

Code reviews/inspections are by far the most efficient method of finding defects (see any of Humphreys texts), but I find reviewing someones code horrendously laborious and boring. Software is notorious for having out of date or non-existent designs, why? Because documentation is boring. Testing? Boooorrrrrring. Coding however is lots of fun! Thats why I became a Software Engineer. Thats why we have a thriving open source community. Thats why there is so many really bad quality products out there.

The problem with Software Quality is that it is not FUN. I don’t know if it can be fixed, but thats the way I see it.

Comments are closed.