Boycott Radar

Until further notice, I’m boycotting Radar. No more filing bugs, no more responding to bugs. For me, Radar is both frustrating beyond belief and also a waste of time. I recommend that my fellow Mac developers join my boycott, if for no other reason than to preserve whatever sanity and mental health you have remaining. I’ve come to the conclusion that life without Radar will be happier and more productive.

In order of importance (and annoyance), here are my major complaints about Radar:

  1. Mindless responses to bugs from Apple zombies … err, employees
    I expect a knowledgeable person to read and evaluate my bugs carefully. I’m sick and tired of getting stupid, sometimes irrelevant responses. It’s clear in many cases that the Apple employee was basically skimming for keywords and didn’t bother to actually read the bug. And I’m far from alone here: I’ve heard numerous examples (otherwise known as horror stories) from other developers of the same kind of maddening response to their bugs. We developers spend a lot of time discovering, investigating, and reproducing these bugs for Apple, without receiving any compensation. Inexplicably, though, Apple employees are dismissive of our help. They seem to care more about closing the Radar than fixing the bug that the Radar reports.
  2. Duplicate bugs are second class citizens
    If your bug gets marked as a dupe, you’re doomed. Don’t expect to ever hear about it again, not even if it’s fixed. Apple’s canned response says, “To request the status of the original bug, please update your report directly via the Apple Bug Reporter”, which is ridiculous, because you could have dozens or even hundreds of duplicates, and it can sometimes take years for a bug to get fixed, so how often are you supposed to make status requests?
  3. No searchable bug database
    If you’re lucky, an Apple engineer on a mailing list may tell you that your problem is a known issue. If not, you could flail around for days trying to figure out why your code that should work doesn’t work, because of a Mac OS X bug. A number of other companies provide searchable bug databases to their developers, why can’t Apple? It’s true that sometimes your bug reports contain confidential information that you don’t want to share with other developers (your competitors, for example), but often they don’t, and it would be nice to have an ‘opt in’ option to allow other developers to see your bug. It’s also true that Apple needs to protect its secrets; however, Apple should realize that not everything is or needs to be secret, and as ADC members we’re already bound by Non-Disclosure Agreements, so what’s the point of being under an NDA with Apple if Apple never discloses anything to us? The existence of Open Radar demonstrates how ludicrous it is that Apple does not provide a searchable bug database themselves. Although I don’t post my bugs on Open Radar because I don’t have a Google account, I do have a list here.
  4. Wasting my time asking me to verify unfixed bugs
    Apple employees seem to think third party developers have nothing better to do than perform unpaid QA work for Apple. A number of times, I’ve gotten requests to verify that a bug still exists in software update X, and indeed it does still exist in software update X, as demonstrated by the very steps to reproduce that I listed in my bug report. Did anyone at Apple even bother to follow my steps? (That’s a rhetorical question — obviously, no.) What were you thinking here, that my bug would magically disappear without having to do anything? Sorry, your deus ex machina failed to show up, stop wasting my time and start fixing the bug. If Apple is understaffed, and its employees are overworked and don’t have enough time to do this themselves, that’s not my fault. If I hear one more excuse about Apple not having the resources, I’m going to puke. Or punch someone. Or puke on someone’s fist. Apple makes more than a billion dollars a quarter in profit. My company makes slightly less than that.

What I’ve come to realize is that we developers don’t need Radar. Apple needs us, but we don’t need them (for this, anyway). The time between filing a bug and seeing a fix for the bug shipped in a Mac OS X software update is usually quite long, sometimes infinitely long. If I discover a Mac OS X bug that affects my software, I can’t wait for a fix from Apple, I have to write a workaround immediately. Thus, by the time I file a bug, I don’t really need a fix for it. The sole purpose of filing the bug is to help other developers and to make the Mac OS X platform better. Essentially, it’s charity work. If Apple makes charity work for them really difficult and annoying, then I’m going to find something better to do, like adopt a cat, or a highway.

14 Responses to “Boycott Radar”

  1. Peter Hosey says:

    In Apple’s defense, there are two sets of people who can respond to a Radar report:

    QA people, whose job is solely to patrol Radar. They do not fix bugs or add features; they merely curate the system. See App Store Mercenaries.
    Actual “engineers”, who work on the products you’ve found bugs in. These people really are of limited supply and have limited time, some of which needs to go into actually fixing bugs and adding features, and not just fielding Radar reports. Throwing more people at the problem is not a solution; see The Mythical Man-Month.

    It’s a hard problem. The number of developers is going up, which means (I would hope) that the number of bug reports is going up. I wouldn’t expect that the number of engineers per product to fix those bugs is going up much faster than replacement rate; that leaves the QA groups, whose job definitions may still be open to the kinds of problems Daniel Jalkut wrote about.

  2. Peter Hosey says:

    Also, I should point out that I don’t work for Apple, so I have no first-hand knowledge of their internal layout. It’s all second-hand for me.

  3. n[ate]vw says:

    I’d agree with Peter: if you can get your bug to the right person, good things can happen. One thing I’ve found helpful is to politely post to the relevant mailing list either before or after filing the bug. If it’s a bug in developer tools or libraries, the engineers are relatively easy to draw out of the wood work and are eager to make things right.

    But with other types of bugs, I’d agree with you: there’s a decent probability that your time will be wasted. If you have something specific and clearly wrong in an app, it can still be helpful. If it’s a matter of opinion or would confuse an Apple Genius, you might as well tell it to your hand.

  4. Mike Lee says:

    Radar is a massive system for tracking the problems of a massive engineering organization. It’s the only way engineering knows what needs to be fixed. Your direct line into Radar gives you a way to give your feedback directly to the people who can do something about it. It does not, however, make you the only person in the world. Taking Radar personally is like punching a bus.

  5. Prior to joining Apple in 2003, I had filed several hundred radar reports via the bugreport.apple.com UI. Yes, it ain’t great, but it works.

    Overwhelmingly, the radars do get fixed, the product(s) do improve, and the input from various external developers is extremely useful. Sometimes it takes a long time — I recently verified as fixed a handful of bugs that I filed in 2000, 2001, and 2002.

    Even if it feels like your bug is falling into a black hole, it is not.

    For duplicate bugs, it is almost always the engineering team itself that makes the duplicate call. Furthermore, when a bug is duplicated, anything uniquely useful from your now duped bug is generally captured directly or indirectly in the original bug.

  6. Jeff says:

    Peter, I do believe that most of my issues are with management and ADC/WWDR/DevBugs rather than engineers, but as you say, it’s hard to tell from the outside. Nonetheless, I’m skeptical of claims that Apple somehow can’t find enough good engineers. I know lots of good ones myself, but I don’t see that Apple has made much effort to hire them.

    Mike, I’m a solipsist, so that’s where you’re wrong. Anyway, I am a person, last time I checked, and I demand to be treated as a person, not simply a cog in Apple’s giant profit machine. If I’m not, I’ll walk away. By the way, although I’ve never punched a bus, I have in fact punched an airplane.

    Bill, I’m sorry to say that your comment sounds like a canned response. I don’t get the impression that you read and understood my post. Notice that none of my 4 complaints was “My bugs never get fixed.” (The little devil on my shoulder is screaming something about irony right now.)

  7. Mike Ash says:

    Bill, I think that you have particularly misunderstood the duplicate complaint. Nobody expects their bug NOT to be flagged as a duplicate if it really is. And everybody expects that relevant information is pulled out of duplicates when they’re flagged.

    The problem is that, for an outsider, once your bug has been flagged as a duplicate you no longer get any information about it. Apple needs more information? It goes to the original, not to you. Apple fixed it in a seed and wants verification? You’ll never know it. Apple shipped the fix? Hope you noticed the one-line mention in the release notes, if it even merited one.

    Any bug system MUST flag bugs as duplicates. It’s just inevitable that people will submit multiple bugs about the same problem. But most systems allow the person who filed a duplicate bug to still find out about how the original is progressing. That Apple does not makes us all extremely fearful of filing a duplicate, because as soon as our bug is flagged as a duplicate, all interaction with Apple would end.

    If Apple kept doing the exact same stuff they’re doing now, but allowed us to start tracking the original bug when one of ours is flagged duplicate, this complaint would go away.

  8. It was a semi-canned response; I was in a rush and mostly just wanted to say “Please don’t stop filing bugs!!! please please please!!!”.

    (1) The radar front line exists to route stuff as quickly as possible and to ask for more information directly, when it is obviously needed. Unfortunately, the front line often doesn’t have anywhere enough information to really know what questions to ask or even if further information from the developer is required. It helps if you title your bugs appropriately: “Cocoa: etc.etc.etc”, “Garbage Collection: etc.etc.etc”, “Xcode: etc.etc.etc”.

    (2) Dupes are second class, but a very important second class. However, the duplicates are considered when analyzing the master bug and, often, more information is asked of specific duplicate filers that have a unique or more informative bug. Generally, though, once there are more than a couple of dupes, more information isn’t needed.

    (3) There are many reasons for a non-searchable bug database, most revolve around secrecy. Not just Apple’s, but external developer’s secrecy, too. And by secrecy, I don’t mean just product secrecy, but also intellectual property protection, too. There is a big bundle of potential liability there and to address it would require a bunch of resources beyond engineering.

    (4) If you send me email containing bug #s of bugs that are frustrating you, I will double-check on the bug. I may not respond beyond saying “thanks”, but I’m always happy to double-check (see (3) — it is the way it is).

  9. I find Radar extraordinarily frustrating, maddening really. Several times I’ve had people ask questions about how to recreate the bug that would have been avoided had they actually read and followed the steps I posted. (Along the nature of “How did you open that window?” when my steps include something like “Hit command I to open the window. DO NOT use the mouse to choose Get Info from the File menu.”

    I don’t think boycotting Radar will help at all, unfortunately. Though I’ll admit I’ve already got frustrated enough that I’m skipping filing some bugs. I probably see twice as many as I file these days, and that’s not even counting feature suggestions/SDK deficiencies.

  10. Mike Ash says:

    Apple people constantly jump in to beg us not to stop filing bugs, which I fully understand, but never jump in to actually talk about fixing the problems we bring up. Frankly I’m not interested in reading Yet Another Discussion of how important it is that we file bugs, how valuable it is to Apple, how much the engineers appreciate them, etc., since I already believe these things anyway. All I care about is actually improving the system, not attempts to convince me to keep using it as-is.

  11. Bill: Why can’t the Bug Reporter at least show us the status of the original for our duplicate bugs? I understand not wanting to show us anything else about the original, but surely letting us know if it’s actually being worked on wouldn’t be a security problem.

  12. Todd Thomas says:

    So to conclude I think if you want to see some changes happen to radar you should…umm.. file a bug with radar :-)

  13. Patrick Mau says:

    I recently filed my first real radar for Mail.app, spending a lot of time deleting my preferences files and Smart Mailbox settings to collect lots of details on my issue. The only thing I got back was that my bug is a duplicate. Judging from the duplicate bug number in the state column, I can only assume that the bug exists for a long time.
    This is really not useful at all and I will certainly not spend my time again to just get notified that all my investigation is “old news”. I know people have posted similar remarks, but I’m really frustrated.