Just ran across this old post by Daniel Pasco, which showed again up in NetNewsWire presumably because of some RSS reboot on their end. Anyway, it reminded me of dealing with 3rd party developers – mostly indirectly, through Developer Relations – and the trials it involved.
I particularly like the captioned picture of Mike. Nice. I don’t even know if I ever actually heard him say that, but I can totally hear him saying it now, in my head. :D
It was a source of great frustration that developers would stubbornly fail to file bug reports. Even when I specifically told them it’d be a really great idea and super helpful. Even when it could only take them all of sixty seconds. Literally. “Copy this email you just sent me into bugreport.apple.com and submit”. Yet they wouldn’t.
I can sympathise, of course. Prior to working at Apple I dealt with the other end of the stick, and I had all the same trepidations and frustrations as developers do today – the opacity, the propensity for bugs to be closed without apparent resolution, etc. But my sympathy for you won’t get bugs fixed.
There are some things about the process which are a bit wonky, and could be improved. But not as many as people think. For example, to address the perhaps most beaten dead horse: Apple can’t just open the database, because it’s a legal nightmare, which would make it a practical nightmare. Someone submits some sample code which some competitor sees and the lawyercats descend and that’s the end of it. So code snippets or any details of anything even vaguely proprietary would have to be banned. Even if that were enough, the result would of course be a shitty experience as people try to describe things in abstract. Any mechanism that tries to provide flexible permissions would still suffer from the fallible human element. The only practical solution really is 3rd party solutions, like OpenRadar. Apple has absolutely no affiliation with nor endorsement of them, so it’s safe for them.
Even as it is Apple’s not entirely happy about the Radar system. Developers do submit all kinds of proprietary information and code, unsolicited, which is presumably tenable because Apple never shares it, but it still makes Apple’s lawyers uneasy. There’s all sorts of awkward situations like “Wait a second, this new iPhoto filter is exactly like the one I was developing and attached sample code to in this Radar report! OMG WTF hacks!!!1!”. It’s one of the reasons Apple doesn’t encourage suggestions for their products – it’s just not worth their risk.
Anyway, I digress. Practical tips for filing radars:
- For fuck’s sake, file them. A radar from an external developer is worth 5x that of an Apple engineer. It’s a way to say “look, here’s someone that’s seeing this problem”. Duplicates don’t always count. It’s unfortunately true. But they do in many teams, and you can force them to regardless – a radar with twenty dupes is likely to become a bit notorious. No product manager wants that associated with them. Radars approaching a hundred dupes are likely to become known to a significant portion of the company. If there’s really hundreds of thousands of iOS and Mac developers out there, it should be embarrassingly trivial to get a hundred dupes.
Have you ever wondered where the name “Radar” comes from? Because if it’s not on the radar, nobody thinks about it. - You don’t need to include great detail up front. Just don’t be surprised if you’re asked for it. If you don’t have a good example handy, that’s fine – it may be it’s a known issue and it can already be reproduced internally. Save your time. And your relationship – submitting bug reports in the form of a thesis is one of the best ways to become alienated from the process.
- Be entertaining. Seriously. It’s social engineering – make the reader of your bug report like you. They’ll be much more inclined to help you out. Coming across as angry or even just frustrated might get you sympathy from the more empathetic engineers, but it won’t get you nearly as much action. There may be parallels here to other types of relationships.
Funny example code is a great way to do this. Maintain a conversational tone, and feel free to insert some dry wit. Bonus points if it’s at your own expense, or in some other way clearly defusing. Your bug might be read after one written by someone who didn’t follow my advice, so the reader may already be in a grumpy mood. - Convey a sense of proportion, preferably through honesty but if nothing else sarcasm. If you try to convince the reader that fixing your bug is the most important thing they could possibly do with their life, you’ll almost certainly come across as entitled. It’s a turn off.
- Respond. If you do get asked for more details, try to provide them. If you can’t, say so. Otherwise your radar will sit in limbo waiting, until eventually it’s closed due to the lack of contact.
- Provide routing suggestions. The first port of call for your shiny new radar is someone in Developer Relations, who won’t necessarily know everything there is to know about every API. In addition to classifying your bug correctly using the pop-up menus, feel free to make the first line “This should probably go to the <Foobar> team”.
- Lastly, just because I’m guilty of it too, man up and confess when it turns out to be a bug in your own code. Don’t waste their time. There’s nothing wrong with filing a bug a little speculatively, so don’t feel ashamed. And it can be helpful even so – maybe the API in question isn’t technically buggy, but if a lot of developers are hitting the same issue, it could be a sign it’s just badly designed. It’s all good feedback.
Great insight! How much of this applies to filing hardware radars?
I can’t say with authority, since I never worked as a hardware engineer on hardware. I do know a few, though… based on what I saw and heard from them, off the top of my head, I’d say they care about reproducibility a lot more. As a software engineer at an application level, it’s plausible to go through your code, with a known failure mode in mind, and find that one “<” that should have been “<=”, or whatever.
Not so – or at least less so – in hardware because it’s rare for any one engineer to have access to all the relevant “code”; there’s a lot more horizontal segregation. Is it the driver kext? The kernel? The device firmware? The cable? Electrical? Mechanical? So a lot of hardware issues seem to pivot on pinpointing which layer is at fault – i.e. who’s responsible – and passing it on to them. Especially when you’re talking about graphics issues, for example, since that’s a big chunk of hardware not made by or necessarily transparent to Apple.