Design, for my purposes, is about making tradeoffs.
-- Joel Spolsky
Strong design decisions are guaranteed to rub some portion of your audience the wrong way, but, if they're good decisions, they make something beautiful, usable, useful. You just can't do that without some portion of the world thinking you're arrogant because you think you know how to do everything right.
The problem here is that there's a range of fairly nuanced responses that we should be giving, but these questions just come up so often that it's not easy to give the right answer every time.
Let me explain. There's a few things your average new user thinks upon poking around in FogBugz for the first time:
- How do I make a field required?
- How do I make this case go away until that case is done? (Dependencies or blocking.)
- How do I delete a case?
- How do I add a custom field?
Each of these has its own, nuanced answer, but, too often, our response has been some version of: Look, we've thought about this a lot and we don't have time to explain exactly why, but trust us. We're right. If you really want to make this mistake, though, here's a workaround, or at least an idea for how someone could code up a workaround. How odd that someone would find that arrogant! So, I'm going to take these four frequently asked questions and break down the design thinking for each of them.
For required fields, I think we've accurately elucidated why we think they're a bad idea, and we unapologetically recommend against them (and not just for bug tracking software). Short answer: if you need this, we urge you to re-examine that need. If you find that you absolutely need a required field, and aren't willing to try one of our alternatives (contact me for these), then FogBugz is not going to work for you.
This is what I'd call a design stance. We've made the decision for the purposes of our software and we're not likely to change it. A design stance comes with its own trade-offs. You have to convince the potential customers who disagree with you, or they never become actual customers. We've examined this trade-off, and we're okay with losing the occasional sale.
Dependencies and Blocking
First off, we're never going to do Bugzilla-style blocking. We feel the downsides far outweigh any potential upside.
But, the problem Bugzilla is trying to solve with blocking is still a problem that needs solving. Some might argue that it's the primary problem that project management software needs to solve. Our software should make it as easy as possible to answer the user's question of: What should I be working on right now?
With FogBugz 7, we put considerable effort into making it easier to organize your work. Allowing you to manage your software project is what we're trying to do here. In our view, allowing case A to hide case B does not get us or you closer to that goal. There are smart, reasonable people who disagree with us on this. That's cool. See above.
Now we enter into territory where there's clear use cases for what you want. Case deletion comes up again and again. In this case, it's not something that we disagree with. It's something we haven't done because of the combination of workarounds (e.g., deleting from the database directly) and other pressing development needs (e.g., a plug-in architecture) have delayed our addressing it. We intend to do so in a future version.
The problem here is that, because we haven't been consistent in our communication, the justification of a resource allocation decision has been confused with a design stance similar to our stance against blocking and required fields. Giving the design stance answer when what you've really done is made a resource allocation decision is a guaranteed way to be called arrogant. And guess what? It worked!
The resource allocation decision simply weighs the amount of effort it would take to do something right, the availability of a workaround to lessen the pain of waiting, and the amount of user benefit we could expect to see. We compare the various things we want to do, and the ones that have the greatest bang for the buck go into the next release. On the user end, it's not always immediately apparent why something is farther down on this list, which is why we often get the question that Joel has used as the title of his column for Inc. magazine.
The answer: Hard enough, or with low enough net benefit, that there was something else we decided to tackle first.
We don't have a design stance against case deletion. It just hasn't made sense to do it yet. There are reasons which I'll expand in this answer once I'm done here.
This is a perfect example of a frequent request that was above the line and made it into FogBugz 7.
While we still maintain that adding a bunch of fields is a recipe for fewer bugs being filed, it's less damaging than requiring a field. We offered two text-only "extra" fields as sort of a stopgap, but there was still need for, and requests for, a robust custom field solution. Now that we've delivered one via a plug-in, there are further requests, but we've gone a long way toward satisfying this question.
In the end, it was a resource allocation decision, not a design stance, and so we eventually found that we had the resources to offer this functionality. Our plug-in architecture has lowered the bar for accommodating a lot of frequent requests, so we hope to be able to say the same about case deletion, rich text, case editing, and a host of other oft-requested features.