Unfeature 1: Emailing Ticketsby Matt
Bugrocket's most important feature is its lack of features. We talk about this in our manifesto. The idea that simple is usually better, less is usually more, and complexity is almost never good is embedded in our DNA. This creates a bit of a dilemma for us: We love hearing from our customers, but they often ask us for new features, and we usually say no. Of course the answer isn't always no. For example, we're working on an API, and this is one of our most often requested features. But the answer to a feature request is virtually always no. So we thought it would be useful to talk a bit about why we say no to features.
Opening tickets via email is high on the list of frequently requested features, and we aren't going to touch it with a 10 foot pole! Emailing in tickets is a great example of a feature that sounds good, but we're pretty sure would be terrible in practice. Which project/list would the ticket be placed in? Who would it be assigned to? How do we handle attachments? Who can create a new ticket by email? How do we do security to make sure that only people who have access can open tickets? When we get the security model wrong the first time, which we will because security is hard, how much time will we devote to fixing it? How much space do we have to use in our UI to configure & verify this feature? There are answers to all of these questions, but there are always trade-offs.
For Bugrocket, the trade off we're most concerned about is complexity. Adding features to the product adds noise and distraction. The more complex a feature is, the harder it is to understand, and the more specific the use case it addresses. We're sure that if we went to work on it, we could develop a usable, maybe even a great method of opening tickets via email. But we're even more sure that for the majority of our users it would be nothing but clutter. And we think that there are better answers for the user who would use it.
Where we're headed with this is an API. Our customers are by definition developers. An API to create and update tickets is not rocket science, and it's fantastically general purpose. We don't need to sell anyone, nor do we need to be sold on the benefits of an API. But most importantly, an API won't add any noise to the Bugrocket app. So we're kind of turning this first un-feature into a feature, just not the one we're being asked for.