Bug Splitting

Every month or so in the Apple Developer community, it seems we debate the process of filing bugs. Does Apple care? Do the bugs go anywhere? Does the system work? Is it possible to do better?

For the most part I agree 100% with Marco on this:

From our point of view, there’s little reason to file bugs. Filing a good bug report takes a lot of testing and time, and it seems like Apple just disregards most of them. Of the few that get any response at all, it’s almost always a useless response or the obvious result of a careless engineer trying to clear out the bug backlog with as little work as possible.

As with any community as big as ours, there are always those that disagree. The principal one I see coming across my timeline is Daniel Jalkut. He, unsurprisingly, wrote a follow up post to Marco:

If we developers want Apple’s platforms to work as well as they can, the sad and short truth of the matter is we have to report bugs. If you’ve only reported 15 bugs over 6 years, as Marco has, I’m afraid to say that you haven’t done enough.

Yes that’s right kids, you just need to try harder to get daddy to love you. He really does, he just doesn’t show it much. And yes his actions often suggest that he doesn’t even know you exist, but you know, you gotta keep trying!

I personally think the Apple bug reporting system is entirely broken. But rather than whine about it, let me show you an alternative way. A few weeks ago I had an issue with a Google API I was working with. It worked one day, the next day it was broken by an overnight software update they’d done. Luckily Google runs an Android Community for the framework I was having issues with, Chromecast. So I posted a question there:

Screen Shot 2014-05-28 at 10.13.41 am

I had a response from a Google Engineer within the hour, pointing me to the post about there being a recent update. I read that, and then decided to file a bug about it. The bug was fixed that day, and Google rolled out a fix for it into production. My bug can be found here: https://code.google.com/p/google-cast-sdk/issues/detail?id=265.

So is there another way to do bug tracking that is better? I’d say yes, with a certainty. There really is one fundamental thing that needs to change, in order for the whole thing to change. It’s rather simple, but are you ready for it? Make a new Bug Tracker where all bugs are public. If ‘public’ means you need to log in with a developer account that’s ok. The point is that once bugs are searchable everything gets easier. When I come across a bug I can search for it in the bug tracker. If it exists, I can instantly see if there are any workarounds, and if not when it might be fixed. Ideally I could up-vote or star that bug as well, to indicate I’m having the same issue. If the bug doesn’t exist, then I know I need to take the time to write a really detailed bug report so that others who come across it with the same problem can attach themselves to it. This would offload some of the curation work to developers as well, something that Stack Overflow has proven that we love to do, and are good at.

So what are the downsides of this approach? Firstly the most obvious criticism is that some things are under NDA or have to be private. That’s easy, allow private bugs and attachments. 99.9% of the time my bugs don’t need to be hidden from the world so there’s no reason to obsess over this part. The other massive downside for Apple is it makes their action (or lack thereof) open, and visible to the entire world. If there are 60,000 bugs that haven’t been touched by an Apple Engineer then we all know. Desirable for us, but I can understand how that’s a scary thought for them.

I could go on about employing technical Developer Relations people instead of marketing ones, about being more open, about setting up communities. But really if Apple could do this one thing…most of our problems would be solved. Or you know, we could keep going with the approach in this flow-chart I knocked up.