Norvin Leach
MSDN Online News Editor
October 27, 1997
You can usually draw a lesson out of any painful experience.
Take last week, for example. On Wednesday, Microsoft's internal e-mail system got slammed by a manifestation of the bozo factor.
Here's what happened: Our IT people created a group alias to test mail distribution, but they forgot to set delivery restrictions. Normally, that wouldn't have been a problem, but someone discovered this test alias, couldn't figure out why he was on it, and sent mail to the whole alias asking, "What's Bedlam DL 3?"
People started responding.
"I don't know what this alias is."
"I don't know either, but take me off."
Then came the complaints. Smug and self-righteous, the complainers demanded, "Don't Hit Reply All!!" But, of course, the senders sent this instruction to all the people on the alias.
All 18,000 of them.
The system slowed to a crawl. Our IT department figured that a month's worth of e-mail went through the pipes in a single day. On a normal day, we average four million messages.
Well, it's not a criticism of Exchange, which stayed up and running throughout the incident. And it's not an excuse to vent about these pinheads.
My point is a simple one: You never can tell what users are going to do with your software.
This is the bozo factor—some hopeless stupidity that you never conceived when you were planning your applications.
Okay, so these inadvertent spammers weren't as brainless as the people in the help-desk horror stories. You've heard about them—the people who photocopy floppy disks or close the windows in their office instead of shutting down Windows or Microsoft Office.
And it's true, you could attribute The Bedlam Horror to problems of implementation, not design.
Nonetheless, last week's combination of events was one of the unexpected problems that developers have to face. It's a paradoxical argument—expect the unexpected. You can take comfort, though, in the fact that after a problem appears for the first time, it's no longer unexpected. You can then begin to work on solving it.
Well, look at where our industry is going. Applications are becoming more complex. Networks are becoming more labyrinthine. Systems architectures are becoming incredibly elaborate. Planning for the bozo factor is only one of the things to consider when testing applications.
Testing. It's unglamorous. It's time-consuming. And it's no fun when someone highlights the flaws in your code.
But I've always been surprised at the number of developers who don't consider testing to be a priority in the development process.
I'm not just talking about debugging. I'm talking about software-quality testing. Profiling. Checking for memory leaks. Load testing. That whole bundle of expensive tools that maybe your company decided to pass by.
I'm also talking about usability tests, screenings, and other steps to make sure that your software is understood.
The bozo factor might pop up anywhere, like a malignant jack-in-the-box. But it's not a hopeless case, as long as you commit yourself to thorough testing of your applications.
The software-testing industry is keeping pace with the advances in software technology itself. Last year, for example, a lot of the testing companies began offering Web-application testing tools. And if you're using the latest technology in development, you owe it to yourself to use the latest testing tools as well.
Not only will your software be better for it, but you never know when you might discover and close up a potential loophole for the bozo factor.
For more information on testing and development, we have a number of items in the MSDN Library. Most of the product SDKs include testing information, and The Windows Interface Guidelines for Software Design (Books, MSDN Library) also includes sections on testing.
Do you have horror stories about misguided users? Send them to me via e-mail (it's working now).