It's a weird, nice feeling watching your software in use well beyond it's planned - or more frequently, assumed - obsolescence.
We called it RAID because it kills bugs dead
11–20 of 128 posts
Re: We called it RAID because it kills bugs dead
#12Google's counterpart is called Buganizer. I've seen bugs in it dating back a decade or more. I don't know what, if anything, was in place before Buganizer. They might be exposing some version of it externally as well now: https://issuetracker.google.com/, although the UI bears little resemblance with the internal version I used years ago, so it's probably a separate product.
What Raymond's article does not mention (or at least I don't think he does, I have only skimmed the article) is that at MS each team had _its own_ bug database. As a result, even filing a bug in another product was an ordeal, let alone fixing bugs across products. What this friction means in practice is nobody would bother unless they really couldn't live without a fix. I think you can easily see the results of that in Microsoft products today.
At Google, _everyone_ uses the same bug DB. If a BigTable bug affects something in Ads, you can create a bug for BigTable and reference it in a bug under Ads, which is, IMO, the way it should be. Moreover, you don't need to get bug database permissions for BigTable, because you already have them.
Re: We called it RAID because it kills bugs dead
#13Fun fact: Apple's internal bug tracking tool, Radar, traces its origins to a pen-and-paper tracking system from the very early days. In a similar fashion to RAID from the article, it's use expanded way beyond the original use case and is now used by nearly every team at Apple, from hardware, to test, to marketing, retail, and everything in between. It's often the butt of a lot of jokes as most people hate its dated a…
As far as I can tell, most teams think Radar is the best bug tracking tool ever. Externally, it's extremely frustrating to interact with, even more so through Feedback Assistant.
Actually you bring up a good point - the reactions are perhaps more bimodal than anything. If you're on one of the teams it was designed for, it is indeed near perfect. If not, it's far from it.
Re: We called it RAID because it kills bugs dead
#14Google's counterpart is called Buganizer. I've seen bugs in it dating back a decade or more. I don't know what, if anything, was in place before Buganizer. They might be exposing some version of it externally as well now: https://issuetracker.google.com/ , although the UI bears little resemblance with the internal version I used years ago, so it's probably a separate product. What Raymond's article does not mention (…
I think the Material UI is new, it used to look a lot different when I used it externally (back in 2017).
Re: We called it RAID because it kills bugs dead
#15I left MSFT and went to Viair (with folks from the MSN Mobile and Outlook Express team), and we didn't have a bug tracking system... so we had someone send us a few screenshots of RAID and built a VisualJ clone one weekend. Fun side project, didn't really want to be in the business of bug tracking, was slightly before the web app era... We called our bug tracking system "BlackFlag" because it was a competing brand of…
I feel like I'm watching an episode of Halt and Catch Fire. Thanks for sharing!
Such a great show. I wish more people knew about it.
Re: We called it RAID because it kills bugs dead
#16And if you have disks in RAID a bug in it kills your data instead. ;-)
I was startled that they used the name RAID given the Berkeley RAID paper... but on checking the dates, they would have needed a time machine to realize that this term was about to become heavily overloaded.
Re: We called it RAID because it kills bugs dead
#17Sometimes I think bug tracking doesn't get enough attention. It's gotten a lot better these days but compared to source control, bug tracking seems to remain the red-headed step-child.
Bugs can be just as important as source code - if a line of code is changed and all the comment says is "bug 1234", then hopefully bug 1234 has context about the scenario that was broken, a history of a conversation between QA and development, and signoff from QA with whatever was verified.
Sure, this might fall into "write a good commit message", but obviously that doesn't always happen, and having the historic knowledge of the bug tracking database at your fingertips is important.
Re: We called it RAID because it kills bugs dead
#18> Unfortunately, the archive project renumbers the work items. Fortunately, the original work item is remembered in the title, so you can do a search for originalid:3141 to find the old work item known as number 3141.
I wonder what happened if a bug was carried over for 2 or more databases.
Re: We called it RAID because it kills bugs dead
#19I remember using RAID when I worked at Microsoft from 1993-1996
Re: We called it RAID because it kills bugs dead
#20Sometimes I think bug tracking doesn't get enough attention. It's gotten a lot better these days but compared to source control, bug tracking seems to remain the red-headed step-child. Bugs can be just as important as source code - if a line of code is changed and all the comment says is "bug 1234", then hopefully bug 1234 has context about the scenario that was broken, a history of a conversation between QA and deve…
Personally, I like to mention the ticket number(s) and a description of what changed and why. I wish git would reject commit messages like "fixed".