Question

You think you know how to do everything right. When someone dares to suggest that they need a required field or case deletion, they're met with: You just think you need that. You actually don't. Try doing without it and you'll see how wrong you were to want it in the first place. Trust us. We're smart.

Do you guys ever get tired of being so awesome?

Answer 1

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.

Required Fields

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.

Case Deletion

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.

Custom Fields

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.

Answer 2

I've been dealing with Fog Creek for a couple of years now and I'm thankful they have challenged some of the common assumptions.

My advice would be to keep an open mind and not judge their advice as arrogance. I recently had an in-person meeting with some of the folks from Fog Creek and if anything, they were extremely humble.

Also, to truly understand the philosophy that is FogBugz, go read Painless Project Management. It's a quick read and you truly only need to read the first four chapters. I have run into a great number of really smart people who just didn't understand the philosophy of the tool and wanted to bend the tool to their will. Months down the line, those same people have thanked me for making them understand and preventing them from out-smarting the tool.

Answer 3

I've also had personal interactions with the FB crew and find them anything but arrogant. Not only are they humble (as mentioned by Shane), they're also REALLY OPEN to suggestions on the software. These guys want FB to be just as awesome as we do - probably more so. And they appreciate well-reasoned suggestions. But as Rich said, there are some design stances you have to consider.

This software usually constitutes a paradigm shift. I've had to rethink a lot of how I was managing and statusing projects in the past. I've been using the software for a few years and still find myself stopping to see "traditional project management" through new eyes. It takes a while to wrap your head around it.

To shorten the answer. It can take a lot of thought to understand how they see things. The right answers, then, also take a lot of effort to write up (as demonstrated by Rich). Sometimes, people are human and rely on "trust us."

Answer 4

I have to agree with the "Fog Creek is arrogant" school. We're not children. Don't treat us like we are. I went through hell trying to get approval to use Fogbugz in my company and then when I need something obvious like deleting old data, I hear "we get that request 'again and again'. And not just that, but Joel himself refers to it above as among "a few things your average new user thinks upon poking around in FogBugz for the first time." And yet. NO. We have other things to do that are more important. If you're a fogbugz on demand customer you're out of luck. If the reply to another post is still correct, you can't do it yourself and FogCreek won't do it for you.

And as far as the "we've thought about that alot and, trust us, it's not a good idea" thread goes - I have two replies: First, your customers are mostly software engineers. We understand the concept of deletion. Really we do. Second, if it's such a 'bad thing' then provide logical deletion so we never have to see the old crap again.

If you want another example of arrogance, the change last fall so that all times are shown in hours only is a great example. I wish I had back the hours I spent translating total project and sub-project times from hours into days for my 2,000 person day project.

Next time: Acunote.

Answer 5

I was listening to an old podcast from Joel and Jeff and they made a point that I think applies well to this question. I'm putting it in a separate answer because it's something completely different than my previous answer. The point they made - which I'll put below - was in reference to StackOverflow but it applies here, too.

This type of community exists because people come here seeking expertise. People come here to get answers from experts - not necessarily to see questions which haven't been thought out or even worse - already asked.

If the site is too friendly for "newbs" and is full of easy questions and repeats, the experienced folks will stop coming around because there won't be anything in it for them. Once the experienced people stop coming, everyone else will follow and the site will go dormant then die.

For this reason, a certain amount of "hand-slapping" has to occur to discourage questions that have already been asked or could easily be answered by reading the help file.

Don't get too offended if you find yourself on the business end of a "we've already answered this a bunch of times" or "because it makes sense that way" answer. It might happen to all of us at some point in time and though it might not feel like it - it's actually healthy for the site (as long as it's not overboard).

Answer 6

Hi,

I just wanted to add that I too was frustrated with not being able to delete a case, but found a workaround that works for my team and actually has some long term advantages.

What we do is for every project (and we let each customer have access to their work in progress project) we create 3 Fogbugz projects - CUSTOMER_PROJECT - CUSTOMER_PROJECT_INBOX - CUSTOMER_PROJECT_ARCHIVE

Inbox is where cases are posted and serves as our "Triage" area for new cases by customer. Project is where we have cases we are working on and our backlog. Archive is where old/closed or deleted/duplicate cases go to rest.

This way our Project is clean, we keep are full history thanks to our Archive and our developers and customers are happy.

Jonathan.

Answer 7

There's a big difference between saying this:

You actually don't. Try doing without it and you'll see how wrong you were to want it in the first place. Trust us. We're smart.

And that:

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.

Two explanations:

1. the one who asked this question has changed the way the team answered. My humble suggestion: Rich Amstrong, may I ask you to precise it in the answer;
2. the way they answered first may lead to misinterpretation. My humble suggestion: just try to think that people who are not self-confident will always misunderstand such answers like #1. Thus always try to answer like #2 (which is not easy I do admit).