| COLUMN |
Don't shrug off buggy software |
 |
By Michelle Davidson
03 Mar 2008 | SearchSoftwareQuality.com
|
|
|
|
Michelle Davidson,
Site Editor |
|
Ever have one of those weeks where everything clicked -- everything worked out without a headache? You were able to do your work uninterrupted, people on your team did what was expected of them, your boss answered your questions and you were able to accomplish everything that was asked of you?
That is NOT the week I had last week. Everything seemed to be a struggle -- getting stories from my writers, editing and posting those stories, writing my own articles. At one point I even lost my Internet connection, which is critical for doing my job, due to the blackout here in South Florida. I am fortunate, however, that I did not lose power for hours like thousands of people in the area did.
As I was ending one seemingly torturous day, I had to force myself to remember that no one will die because I or someone on my team didn't do something. A story might be filed late, the system for sending our newsletters may go down, and I may not be able to find webcast speakers, but SearchSoftwareQuality.com -- all of the TechTarget websites for that matter -- will still be there and they'll still be free. They'll still have all the great content we were able to get out that week.
Software development teams can't always say that, however. Often the systems being created can have a life-or-death effect on people. If something is not done properly, not tested or not fixed, people could actually die. Software defects on planes or automobiles can cause deadly crashes, defects in air traffic control systems can leave pilots unable to fly safely, and defective software in medical devices designed to help people could actually hurt them.
David Rice includes many of those types of stories in his book Geekonomics: The Real Cost of Insecure Software. These incidents are real and are a wake-up call for how important it is to create quality software. Software testing, in particular, cannot be overlooked.
In the book Rice talks about typical software engineering practices that "encourages programmers to produce, as quickly as possible, programs that they know will contain serious errors." Such is life that software contains such errors.
I'd like to hope that this isn't true for most software makers. I'd like to think that if they are creating software that could physically hurt someone if it has a flaw, that they'll be concerned and worried about doing their jobs well -- as worried and concerned as I get when my projects aren't a matter of life or death.
|
|
|
|
