Let Users Swat Bugs

Computerworld - Oops. Two weeks ago in this space, I wrote about the importance of reducing errors in software and reported that U.S. software users could save $22.2 billion in lost productivity if software developers made "feasible improvements" in software testing to get rid of more bugs, according to the U.S. government's National Institute of Standards and Technology.
Then, a little later in the column, I referred to exactly the same amount as $22.2 million.
Hey, I didn't say getting rid of errors is easy.
For the record, the correct number is $22.2 billion. And most readers were apparently able to develop their own work-around for this informational bug so they could continue reading the column.
But the fact remains that a spectacularly obvious, thoroughly preventable error got through several layers of QA (in the newspaper business, it's called "editing") and was spotted only by users - er, readers - who helpfully reported the problem so it could be corrected.
Conclusions? Blowhard columnists are just as error-prone as programmers. And QA can help, but we can't count on it to catch all errors - even the obvious ones. And most important, when it comes to finding and correcting bugs, users are our friends.
Or at least they should be. And not just after code (or a column) is out the door.
We should put users in the loop from the very beginning - and keep them there, all the way through.
After all, users know their jobs. They know how applications will be used. They know what they need in order to do business. Requirements and specifications and wish lists are just a thin, pale abstraction of what software is supposed to do. Users can give you the real thing - in real time.
We all know that the best time to find bugs, errors in design and just plain boneheaded ideas is as early as possible, when they're easiest to fix. Which means the earlier we connect users with code, the more they can help us. The more mock-ups, prototypes and early versions we run past users, the more likely they will be to point out the things that don't work before they're hard to change.
Users can tell us which features really matter and which ones are window dressing. They can identify which requirements are changing and which ones are likely to, and in what direction. They can clarify how business processes actually work, what screens and data they'll actually use and where the biggest annoyances show up.
And if