Dumb Bugs
keskiviikkona, tammikuuta 09, 2008
Seth Godin wrote Dumbing Down and it reminded me of dumbing down code and dumb bugs. The latter is what interests me for the moment.
My first and second jobs were tech support. I graduated from college just as DEC, Wang and Data General were winding down and preparing to fade away. The result was a saturated job market and I was thankful to get the gigs. Those two jobs taught me a lot about software development and how bugs really affect customers.
The worst bugs were those that didn’t add anything to our products beyond the appropriate level of polish. Bugs like spelling and grammar mistakes, minor UI alignment issues, terminology issues, etc. Customers really do call about these kinds of issues and some customers actually get really angry over them. They have a right to be upset too: they spent a fair amount of money and expect things to look and work right.
Dumb bugs are often really easy to find and fix. Sometimes they get missed anyway or they get a really low priority in the bug database and are prioritized right out of the development cycle. Missing these things is sometimes fine, everyone makes mistakes and some of us can’t spell if it weren’t for spellcheckers. However, they should get fixed quickly once they are entered into the bug database.
It usually takes only 2 or 3 minutes to fix a spelling or nomenclature mistake. Just a couple of dollars to update the code, usually a resource or configuration file, and close out the bug. Its cheap to fix.
Have a customer call and complain about these bugs takes up tech support time and customer time. Tech support time can be cheap unless you have a huge product and receive hundreds of calls a day. Annoyed customer time is a different story. They may get trapped in a long call queue and become progressively more annoyed as time goes on. They were annoyed enough to call in the first place and then they got more annoyed when they had to wait. A customer is not going to drop a product because of minor errors. But they will drop a product if they find too many bugs and thats part of customer churn. Now its expensive.
Tech support lines educate customers as well as improve the product. Tech support staff can log a lot of bugs, the good ones are those that detect an edge case problem such as a crash if you pull up three dialogs in a certain order and drop in a URL in one of the fields. That’s a good bug to fix. Other calls will be about security flaws or other bugs that really improve the product. These are really valuable times for tech support to be there.
Customers will always find bugs. Software is too complex for them not to. What kind of bugs do you want them to call about?
0 comments