Links For Future Use, Years After The Fact

I haven't maintained this site at all, save to point back to the post about Fogbugz actively interfering with developer communication.  I saved a bunch of links in a draft post that I never published. The stuff here is worth saving, so here goes:

• Joel On Software
• Coding Horror: Has Joel Spolsky Jumped The Shark? Excerpt:

  ...[T]wo weeks ago we found out that Joel's company wrote their flagship product, FogBugz, in a proprietary language they created themselves.
  

  FogBugz is written in Wasabi, a very advanced, functional-programming dialect of Basic with closures and lambdas and Rails-like active records that can be compiled down to VBScript, JavaScript, PHP4 or PHP5. Wasabi is a private, in-house language written by one of our best developers that is optimized specifically for developing FogBugz; the Wasabi compiler itself is written in C#.

  You couldn't possibly have heard it, but that was the sound of fifty thousand programmers' heads simultaneously exploding.
  Writing your own language is absolutely beyond the pale. It's a toxic decision that is so completely at odds with Joel's previous excellent and sane advice on software development that people literally thought he was joking. He had to write an entire follow-up post to explain that, no, he wasn't kidding.

• Zed Shaw: Fortune Favors Big Turds. Excerpt:

  I am getting tired of Joel blabbing about his one trick pony FogBugz. I’ve used it and it’s utter total garbage. It’s pain level just happens to be between Trac and a prostate exam from Dr. Edward Scissorhands so some corporations buy it. What’s even more amazing is that he actually manages to sell what is basically a crappy todo list to companies and make some money on it.
  Until Joel can learn enough statistics to conduct a usability study that does a task analysis comparing FogBugz to Trac for developers he can shove it. You see, FogBugz sells because it screws developers for the sake of keeping managers and bean counters happy. It’s like every lame ass tool sold to management. Rather than make a time tracking or defect tracking system that developers can use they make a product that managers love. Slap a few fancy charts and reports nobody will use, present it to an accountant or desperate manager, and sold to the man in the funny hat.

• Google: "joel spolsky wanker". Mostly just for comic value.

All right, as you were

FogBugz 8, And The Lessons Still Unlearned

So we finally upgraded to something like a reasonably new version of FogBugz. Some things that were mercifully fixed:

• Form e-mail finally does get in touch with its inner LDAP. This is good because you'll have to re-fill that form frequently.
• The per-message Reply button is a helpful improvement, but it still doesn't overcome the fact that you don't know who's subscribed to a given bug.

Things that still suck:

• TOFU quoting still reigns supreme. It can't be overridden or eliminated in the web user interface.
• "Reply" doesn't reply to the last person modifying the bug. Instead, it seems to reply to the person(s) addressed in the To and or CC fields in the last e-mail.
• "Reply" generally defaults to the FogBugz user instead of the actual sender. The problems with originator don't seem to have been addressed more generally.
• There is an ambiguity in the "AssignedTo" search axis in the documentation; it means "currently assigned to", not "was ever assigned to". (Incidentally, what kind of weird nomenclature is "search axis", anyway?) This is really terrible, because I dispatch a lot of bugs that ultimately go to someone else, but if a bug was once assigned to me that is very necessary to know.
• Time ranges are inconsistent. I can say, for example, "last month" or "last week", but not "last 4 days" or "last 2 months".

The rest of the issues I wrote about earlier remain unfixed.

Communication, or Lack Thereof

The first and most vital thing we do as programmers is communicate. And yet FogBugz strangely refuses to assist in this activity, at times actively interfering with this process.

• Form e-mail doesn't know about LDAP users. This means if you use the Reply feature, you get to type in the full e-mail address of the person with which you wish to communicate every stinkin' time (unless those persons were on the last e-mail message for the bug). Unlike every other field in FogBugz where you can insert a person into it, it doesn't even give you the option of filling in a name from its own internal list, even though it has e-mail addresses for each and every one of them.
• It's not possible to subscribe a third party to a bug.
• It's not possible to tell who is subscribed to a bug. This is even stranger. Should I ask my coworkers if they care about this bug? I keep sending off one-off e-mails to others to give them the idea that maybe something I'm working on is important.
• E-mails sent from the form do not automatically include a link back to the bug...
• ... or if they do, they also include a _garbage string at the end of the URL that causes bizarre and pointless data dumps.
• E-mails sent from the form do not indicate the actual author. I have to manually indicate that I am the author of the e-mail, since all e-mails originating from the form are identified as being from FogBugz.
• The bug creator and/or current assignee does not automatically get subscribed to bugs he writes/is assigned. Why not? If somebody changes that bug, don't I, as the person responsible, want to know what is going on with it? I could understand it if the person is a management type who only really is interested in state changes or handoffs (Joe Coder broke the frobnitz() method, let him fix it, etc.), but that is an entirely different matter that could be handled with some relatively simple changes. Such as:
• There is no way for management types to be updated on only their charges' bug state changes. The tradeoff I seem to hear from the Fog Creek people — and I would really like to get to the bottom of this at some point — is that the Bugzilla model of bug tracking is fundamentally broken for large, commercial development environments because it assumes everyone has an equal interest in all communication that goes on during development. Clearly, this assumption is incorrect. But FogBugz goes too much the other way, hampering developer communication by making far too many things optional or developer-dependent (bug subscription in particular).
• Microsoft-style TOFU quoting. I realize this is "standard" for some version of that word, but it stymies clarity; point-by-point interleaved responses make the discussion much more straightforward. Making TOFU standard means two things:
  1. E-mail replies from e-mail clients that actually do interleaved quoting are entirely at the mercy of those clients' word wrapping. (Thunderbird, for instance, annoyingly but entirely within the standard, strips all newlines and reformats each paragraph as a single line.) This doesn't help with ease of reading.
  2. TOFUers end up shoving tons of quoted text that is all but certainly redundant with earlier discussions.
• Replying as yourself when using e-mail from the form to reply in a bug causes the bug to silently be reassigned to the writer. Why?
• Lastly (for now), my favorite trivial bug within FogBugz: E-mail using "bug XXXXXX" in the subject spawns a new bug. If you use "case XXXXXX" this does not occur. But this is the only place in the whole package where this equivalence is not recognized.

Enough for now.

Hello, World (Manifesto To Come)

I have had it up to here with Fogbugz. I am a three-year (approximately) user of Fog Creek's unbelievably brain-damaged product, absolutely disgusted with it, and cannot believe that a Google search for "fogbugz sucks" returns so little relevant data.

Despite the title of this blog, I hope to enumerate specific suckage, discover Joel Spolsky's defenses (if any) of his maldesign, and keep it fairly civil.

But I simply cannot stand by while my employer continues to pay for a product that is so badly broken, and hope to influence others looking to make the same poorly informed choice.