When it comes to software development, bugs are the enemy. They can make your software behave in unpredictable ways, creeping and crawling through your code. But bugs aren’t always the fault of the third-party developer—sometimes they have their root in things out of their control—like, say, Apple’s own software.
Apple’s long maintained a system for tracking bugs called Radar, which allows developers to submit problems that they’ve discovered. Unfortunately, Radar doesn’t allow for searching bugs other than ones you submitted, so if you’re looking to see who else might be having similar problems, or whether a particular bug has already been noted, you’re out of luck.
That’s why developer Tim Burks took it upon himself to create an open-source system that allows for those capabilities, based on Google’s App Engine. Since Apple’s own database often contains protected information, Burks took a simple but clever solution: create a duplicate database into which developers could file the same bugs they’re reporting to Apple, but which allows for searching and other features that Radar doesn’t. The system, dubbed Open Radar, has already attracted a lot of attention from devs, who have quickly begun populating it with issues they’ve discovered.
So why should non-devs care? Well, the simple answer is that the more access to information that developers have, the faster they can corroborate and identify bugs, thus the more solid and reliable your software gets. And if Apple happens to take this as a message about changing the way they do business, even better.
This seems like a good idea for some reasons but a bad idea for others.
I'm not a developer but as a database tech I work with a few and in my experience devs usually have an unusually logical but also unusually black and white view of the world. I think these qualities are perhaps the reason why they don't see the obvious flaw in this proposition.
The reason being that "OpenRadar" merely increases the pool of *anecdotal* information on bugs and actually reduces the focus of the bug hunters and submitters. I know developers are unlikely to agree that their bug reports are "anecdotal" and that they actually constitute hard facts, but they really aren't, and they really don't.
More information is usually a good thing, but that's not always the case and it also depends on the quality of information. While you will now have more information about other peoples bugs, you won't necessarily have any more information about *your* bug.
Picture this ... you have a bug and it's now clear that a great many others have a similar bug. The group of them have decided amongst themselves that it's likely code path A that's at fault. Your bug, while similar on the surface is caused by something else (let's say code path B), and is entirely based on the *differences* between your situation and the one described in "Open Radar" not the similarities.
Congratulations. You have just completely changed your focus from the bug in front of you to a *possible* bug that *may* exist in similar situations in other peoples code. It will take you an extra week to figure out you were wrong.
Hi Dan, thanks for the story! Dave Dribin, Joachim Bengtsson, and Jonathan Rentzsch are also involved in this project, and after 3 days, Open Radar has entries on over 250 issues posted by nearly 50 different Cocoa and iPhone software developers.
Non-Developer, I'm sorry about the past experiences with developers that may have led you to your beliefs, but in my experience, debugging is helped by having more eyes on problems. People whose careers depend on their ability to solve problems have to get good at recognizing their biases and learning to look for alternate explanations. We often find those explanations in the process of explaining our problems to others.
I also think that professionals do their best work when they do it publicly. There's a long tradition of professional engineers publicly signing their names to their work, and Open Radar gives a group of us the opportunity to do that with our problem reports.