Wed 13 Aug 2008
Defect or Feature Request?
Posted by Scott Westfall under Dev Management, Other
[2] Comments
SlickEdit is switching over to a different bug tracking system, so I’ve got that topic much on my mind lately. It’s amazing how complex something so simple can be. I’ve never seen a group of developers larger than three agree on how to do it.
I like the generic term, “change request” for all changes in a system. But it’s very important to know whether it is a defect or a feature request. In my lexicon, a “defect” is something that doesn’t work as spec’ed; a feature request is a request to alter the intended behavior. Overall, I prefer the word “defect” to “bug”. “Bug” sounds kind of cute. “Defect” is a harsh, painful word, which is exactly what I want associated with any part of the product that doesn’t work properly.
Depending on who you are talking to, they either don’t care about this distinction or they care greatly.
Customers generally don’t really care which it is. They just want the behavior changed. To them, it is a defect as in “defective”, and they don’t care whether it was spec’ed wrong or implemented wrong—it’s just wrong and they want it changed. Am I any different about the products I use?
As a product manager, I care greatly about this distinction because they tend to address different groups. Defects are typically the chief cause for dissatisfaction with a given product. Generally, customers wouldn’t have bought the product if it didn’t have the features they wanted, but key defects are sometimes discovered only after you’ve purchased. Certainly, if you have many obvious defects they will prevent new customers from favorably evaluating your product. Further, defects in a program add to the burden of development, slowing work on related capabilities.
Feature requests add new capabilities to the system. Though these are beneficial to existing users, they primarily want the existing set of capabilities to work as well as possible. New features are a means to broaden the product’s appeal. They can also provide incentives for customers to upgrade or participate in maintenance programs that include free updates.
Developers are also passionate about this distinction, but for a different reason. For them, the concern seems to be that a defect is considered a personal affront to their ability. I’ve spent more time arguing with some developers whether a change request was a defect or a feature request than it would actually take them to fix the problem (though, not at SlickEdit, of course!)
Balancing priorities for defects versus feature requests is one of the most challenging tasks a product manager faces. There are different voices pulling you in different directions: sales, marketing, customers, and developers. All have different things they want to accomplish in the next release.
At SlickEdit, we try to strike a balance that gives as much as we can to each group. Each major release contains new features that we think can improve how you write code. We also try to knock out as many defects as we possibly can.
