Dealing with Bugs

If you sell software and a customer discovers a bug in your code, it's not a nice feeling. In fact, you get a very nasty sinking feeling in your gut. And the first thing that your gut says is: “shh! don't tell anyone else!”.

If you listen to your gut, you can avoid some temporary pain. But your gut is wrong this time. It's always better to disclose bugs to all your customers. Why? Because most of the time, you are doing them a big favour. Think about it, up till now, all other customers have been getting along just fine. The bug probably doesn't even affect them. Yet. But sooner or later it will and they need to know what their options are.

Imagine you're the customer, you've downloaded a software product, integrated it into your system, (development or otherwise), and now a new release comes along. If things are working fine, you'd rather not bother with the hassle of upgrading. In fact, if your system uses multiple external products and components, keeping up with upgrade cycles is a real pain. So you need to know whether the upgrade is really necessary. The only way to do that is to know what bugs it fixes. If the bug is bad for you, you know you need to sort it out. If not, you can wait till the next major release.

By providing full disclosure of all bugs, fixed and open, you give your customers a little bit of help to manage their own complex environments. If you keep the bugs secret, things tend to blow up nastily every so often.

So that's what I do at Ricebridge. All bugs are accounted for. It means that customers can tell at a glance which version fixes what. And they know right away if they need to upgrade or not.

This entry was posted in Business. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *