21 ms·

We called it RAID because it kills bugs dead

399 points by soheilpro 7y ago

chadd 7y ago
I 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 bug spray. (And obviously we used the logo from the punk band...)
- airstrike 7y ago
  I feel like I'm watching an episode of Halt and Catch Fire. Thanks for sharing!
  - ShamelessC 7y ago
    Such a great show. I wish more people knew about it.
    - jjordan 7y ago
      Never heard of it, but as a tech nerd from the 80's it sounds awesome. Will definitely check it out.
      - unnouinceput 7y ago
        1st season is very good. Rest are crap.
        noir_lord 7y ago
        A bit unfair, first season is amazing, the rest are merely very good - it’s a brilliant show overall though.
        dagw 7y ago
        Really depends on what you want in a show. If you came in expecting a show about people designing computer and solving hard and interesting technical problems along the way you will be become more and more disappointed as the show goes on and focuses more on the characters personal problems and whether or not they get married/divorced/sleep with each other.
        droidist2 7y ago
        Yes, it's very similar to Mad Men in that respect.
        unnouinceput 7y ago
        There is no comparison to Mad Men. MM was good all the way to the final season, with both professional view of advertising world and personal growth of characters. Was perfect balance. HaCF only had that in 1st season, in rest it lost its balance becoming a soap opera, which I can't stand.
        aguyfromnb 7y ago
        >focuses more on the characters personal problems and whether or not they get married/divorced/sleep with each other. This is an unfair summary. There might be a divorce (does no one in the tech world get divorced?), and a relationship (that starts in Season 1, Episode 1 and is a driver of the plot), but it is nowhere near about "who sleeps with who". The show has good character development; would you rather the people not do anything in life, over the 15 or so years the show covers? Halt and Catch Fire is great television that loosely follows the technology arc/personal computing age from the early 1980s through the 2000s. It has great acting and characters, including two strong female leads. If you go in thinking it's going to be about people sitting around "solving hard problems on computers", yes, you will be disappointed. There are coding screencasts for that. It's a shame to discourage someone from watching wonderful television about a subject we're all here for.
- whalesalad 7y ago
  Everything about this story is awesome, especially the fact that you used the same logo from the punk band.
- OakNinja 7y ago
  Fun fact, one of Sweden’s most influential music- and culture journalists was being interviewed on national television about a weird documentary wearing a pink “Pink Flag” t-shirt with a modified Black Flag logo. Beyond meta.
  - OakNinja 7y ago
    The t-shirt was all pink of course.
  - brigandish 7y ago
    Is that a clever way of referring to Black Flag at the same time as Wire's Pink Flag?
    - OakNinja 7y ago
      That’s how I interpret it. I actually asked him on Twitter an hour ago - I’ll keep you posted :)
  - joachimma 7y ago
    Lokko or Strage?
    - OakNinja 7y ago
      Strage!
shepwalker 7y ago
Oh lord, product studio. Back in 2013 the preferred method of filing workitems for a given "wave" was to load this spreadsheet, do weiiird formatting, and indentation, type up all the workitems you foresee for the next sprint and then press a magic "send to product studio" button." God help you if you messed up some of the nesting or wanted to reorder anything - honestly I would just wipe it clean and start from scratch. Ironically my team just finished a product called RAID that was designed to kill bugs in product studio and move them to DevOps. There are still pockets of teams that use Product Studio within Microsoft - the sufficiency gap is real - but they're the overwhelming minority now.
- mc32 7y ago
  Sounds like the product could have been named FLIT, given the finicky nature. [1]https://en.wikipedia.org/wiki/Flit_gun https://en.wikipedia.org/wiki/Flit_gun
- asveikau 7y ago
  I had absolutely zero problems with product studio when I used it from 2008-2011. It was a very 1990s style MDI application, somewhat representing the peak of win32 ux design, short and to the point, and as long as the servers were happy it "just worked".
lifeisstillgood 7y ago
>>> they might have been too scared to write it. When looking back on the origin of RAID, one of the original developers confessed, “It really wasn’t made to last that long. Sorry!” This speaks to me - too many times we think we need clever architecture and well thought out methodologies and ... the most useful tools are a mix of inspiration and timing and luck. Had the developers stopped to plan they would have built something with over 16 bits of primary key - and also made a hundred other "improvements" that would have destroyed all the value MS got out of it. There is a point in this - it I am not sure I know what it is.
- hermitdev 7y ago
  > Had the developers stopped to plan they would have built something with over 16 bits of primary key While true, this was in the 16-bit, Windows 1.x era. Also the ~640kb of RAM era (disks also werent that big either, DOS (v3.x) around that time only supported 32 MB partitions). Not sure which version of DOS Windows 1.0 ran on, I didnt use windows until v3.11 for Workgroups. A 32-bit primary key would likely have been seen as wasteful (not that I'm excusing it) and impractical, because you could likely never practically store more than 64k records on a PC of the day (and even if you could, you wouldnt have an disk left to do anything else).
  - gdwatson 7y ago
    He didn’t say which platform it ran on. Was Microsoft still using Xenix internally at the time?
    - exikyut 7y ago
      Yes, for a time Xenix was used for some proportion of internal development, IIRC for DOS. I think I read that on here somewhere. I unfortunately don't have a citation. Need to get a time machine to take me to whatever point in the future I sort out my bookmarks ._.
- lozaning 7y ago
  On the other hand, temporary fixes are often the most permanent kind.
benschulz 7y ago
I'll take any opportunity to mention John Browne's "The Bug Count Also Rises"[1], which contains the line "The RAID is huge with bugs", referring to Microsoft's bug tracker. It was previously submitted to HN[2]. [1]: http://www.workpump.com/bugcount/bugcount.html http://www.workpump.com/bugcount/bugcount.html [2]: https://news.ycombinator.com/item?id=2740452 https://news.ycombinator.com/item?id=2740452
- dmix 7y ago
  What a poetic (and a little depressing-in-a-good-way) comment. I remember various times of my career being a glorified bug tracker. It's a bad mode to get trapped in with no forward progress. https://news.ycombinator.com/item?id=2740626 https://news.ycombinator.com/item?id=2740626
m4rtink 7y ago
And if you have disks in RAID a bug in it kills your data instead. ;-)
- glangdale 7y ago
  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.
- mirimir 7y ago
  I was wondering about that myself.
jkcorrea 7y ago
Fun 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 and confusing UI :). edit: Though to be fair, the team maintaining it has made massive strides recently to completely revamp the UX which is no small feat given such a wide range of business critical use cases.
- saagarjha 7y ago
  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.
  - jkcorrea 7y ago
    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.
    - daniel_reetz 7y ago
      It was torture. Bimodal is right.
    - lilyball 7y ago
      The UI was old and crufty and it was a pain in many ways to work with. But I really miss it because it’s still better than any other issue tracking system I’ve ever used.
      - PeterStuer 7y ago
        Can you elaborate on what made/makes it better?
khy 7y ago
It's a weird, nice feeling watching your software in use well beyond it's planned - or more frequently, assumed - obsolescence.
- hermitdev 7y ago
  What ammuses me is looking at some of the hard-coded "end of time" dates at previous employers. Instead of using null as an unbounded upper bound (because nulls are hard /s), there are hard coded "end dates". One was 2032-12-31, another 2037-12-31 and usually 9999-12-31. Obviously, these all have problems, especially when used in finance. 2037 makes sense, because 2037 is the year that 32bit linux overflows. 9999 also makes sense. At least none of us will be around, so it's some future generation(s) problem. The 2032 one made no sense to me, and I was never able to get a justification.
  - kaibee 7y ago
    Now that it's 2020, I've been looking for a new year to think of as "the future". 2040 seems too obvious and maybe too far away to really imagine, what just add 20 years? Boring. I think I'll take 2032.
    - Paul-ish 7y ago
      2049, for the year the blade runner sequel is set in.
    - JadeNB 7y ago
      The year 2525—if man is still alive.
m0zg 7y ago
Google'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/ 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.
- saagarjha 7y ago
  I think the Material UI is new, it used to look a lot different when I used it externally (back in 2017).
  - q3k 7y ago
    Yes. You can still access the old UI. https://q3k.org/u/0640089a352229b87077f05752ea415abd19e762889b9d8c346c57b8db863bd4.png https://q3k.org/u/0640089a352229b87077f05752ea415abd19e76288...
- fred256 7y ago
  Buganizer was preceded by BugsDB if I recall correctly
- hyperrail 7y ago
  > 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. Filing a bug in another Microsoft product has been technically easy for a long time. It's true that each product team has their own Product Studio database or Azure DevOps organization, but Product Studio gives you a listing of all PS databases company-wide, and I think you can get the same thing with AzDO. And in both, you can open a bug in any work item tracking database you have write access to. To the extent that you cannot/could not touch bugs or sources for other Microsoft products than the one you work/worked on, that was more a feature of Microsoft's confidentiality policies and corporate culture than of our tools. That is, people in the Windows organizations had access to Office's Product Studio DB or master source repos only if they were specifically delivering features for Office, and vice versa. That attitude is mostly gone now. Since 2013, everyone working on product R&D has had access to most other products' resources, and (IMO) almost no one tries to jealously guard their code against "outsiders". There are still different bug databases for each Microsoft product, but you have permissions to read all of them by default. Exceptions to this general openness and transparency are largely limited to consumer hardware products (Surface, Xbox) which remain very tightly controlled against leaks. (Above is based on my personal experience working for Microsoft in the start and end of the last decade, with a gap in the middle.)
bentcorner 7y ago
Sometimes 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.
- hermitdev 7y ago
  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".
  - sitkack 7y ago
    Train a spam filter and use a commit hook, in Perl.
- bitwize 7y ago
  That is because Industry Best Practice these days is to use JIRA, which lumps bugs in with stories and spikes and other agileshit. They must be planned, prioritized, and pointed alongside all the other work. Ceremonies must be done. The idea that they are defects, and that tracking them and their fixes specially is important, tends to be lost.
- hyperrail 7y ago
  Fossil (https://www.fossil-scm.org https://www.fossil-scm.org ) has an interesting approach to this problem - integrate bug and work item tracking, project wikis, and source control, but make them all distributed, so that there is not a single master copy of the bug database or the docs wiki. It attempts to solve both the cultural challenge (bugbase written by a different company/team from the source control, imposing 2 different styles on you) and the technical one (bugbase and source control don't talk to each other, and so bugs and checkins are not linked).
abiogenesis 7y ago
> 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.
- lilyball 7y ago
  Presumably the archive projects are read-only and therefore once a bug goes into the archive project it never moves again.
  - deleted 7y ago
    [deleted]
- SifJar 7y ago
  I assume it'd be a chain e.g. db 1 - issue 3141 db 2 - issue 12 (originalid:3141) db 3 - issue 4 (originalid:12) etc.
macjohnmcc 7y ago
I remember using RAID when I worked at Microsoft from 1993-1996
bearer_token 7y ago
Who wants to celebrate the 18th anniversary of the oldest open Jira ticket with me? https://jira.atlassian.com/browse/JRASERVER-161 https://jira.atlassian.com/browse/JRASERVER-161
smacktoward 7y ago
The one thing all long-lived systems have in common: nobody ever intended them to be long-lived systems.
- mitchty 7y ago
  There's nothing more permanent than a temporary solution.
- jedberg 7y ago
  The quick and dirty Perl deployment system I built at reddit lasted nine years. Five years after I left. I definitely never intend it to last that long.
  - meddlepal 7y ago
    Even better is when a long-dead system is suddenly resurrected and repurposed for another project. I had a friend at a company I left tell me they were un-mothballing a cancelled platform (killed at the time by an unfortunate acquisition) and deployment system I built several years ago because it was needed again. The whole thing was pretty janky because it was barely past prototype but fairly functional. I wished him good luck and told him to find a new job, because there be dragons. He took the advice eventually, but I did hear they got it up and running again, with some pain. Apparently it is out there chugging along doing its thing once again.
  - smacktoward 7y ago
    My father wrote a dBase application forty years ago that, to his amazement, is still in use in some places today. Inertia is a hell of a force.
    - twhitmore 7y ago
      It probably has more digits for the primary key than the MS bug tracker originally mentioned. Sigh.
  - jnothing 7y ago
naringas 7y ago
it killed them dead by means of tracking and keeping them in an inventory...
ikeellis 7y ago
As an independent dev team working with Microsoft Games in 2002-2003, we used RAID to ship Rise of Nations. It was great! Rockin' fast compared with any web tool now and batch operations were near instant. Sadly it was utterly insecure for remote use and it went away after that game.
- Infernal 7y ago
  I loved Rise of Nations! Mind sharing which bits you worked on?
  - ikeellis 7y ago
    Single player campaigns
zestyping 7y ago
The bug puns were everywhere! When I started working at Industrial Light and Magic in 1998, there was no bug tracker in regular use. I ended up building a bug tracker in Python called "Roundup" (inspired by a program by Alan Trombla, who came up with the name). To create the thinnest veneer of plausible deniability in case the bug spray lawyers came after us, the icon was a little spinning GIF animation of a cowboy on a horse, lasso curled in the air. I only stayed at ILM for two years, but Roundup remained still in use as the ILM software department's main issue tracking system long after I left, at least 6 years later. It was one of the early issue tracking systems that made it easy to subscribe to any issue, so you'd get e-mail notifications whenever the issue was updated. The issue identifiers were numbers prefixed with a code to indicate the affected software project, like "REN003" for a bug in the rendering system. Three digits, of course, because I could hardly imagine that a single project could ever have more than a thousand bugs! I remember that along with statuses like "in progress" and "done", we had a status I've never seen anywhere else: "cbb". As in "done, but could be better." What optimistic software engineers we were back then!
- rconti 7y ago
  CBB reminds me of the pieces of hardware I've labeled as "maybe bad". Only to run across 2 years later, and find myself wondering "who was this 'future me' that I envisioned might be interested in an ethernet card that exhibits flaky behavior under high load when bonded?"
  - Anthony-G 7y ago
    Been there and learned that lesson! Let's waste future me's time by having them figure out in what way the hardware might be bad.
  - exikyut 7y ago
    Well, if it just corrupts packets and doesn't (make the (driver|kernel) crash|bring the link down completely|confuse PCIe so badly the PCH hard-resets) you could use it to build a resilient UDP (or even TCP) packet retransmission algorithm. Not kidding, the results would probably be drop-in usable for cellular/satellite/microwave/etc links, and spotty WAN in general.
vector_spaces 7y ago
The late Joe Armstrong described the similarly minimal Erlang issue tracking system in this excellent post about MVPs https://joearms.github.io/published/2014-06-25-minimal-viable-program.html https://joearms.github.io/published/2014-06-25-minimal-viabl...
KasianFranks 7y ago
No you did not.
sitkack 7y ago
I loved RAID. Lightning fast, so fast that speed was its own quality.
- sitkack 7y ago
  Of all my comments, this is oddest thing to downvote! Is RAID bad now?
  - marvy 7y ago
    seek not to comprehend the downvoters, for it is written: it is simpler to predict each gust of wind in a storm, than to explain even a single downvote or something
    - sitkack 7y ago
      Thanks marvy, this made me smile.
      - marvy 7y ago
        :)
jdsully 7y ago
Product Studio, RAID's replacement was great. I really didn't like the transition to TFS.
badsectoracula 7y ago
> Office cloned the source and built their own custom version I found this bit amusing considering that (IIRC) the Office team also had their own C compiler :-P
philiplu 7y ago
I started at Microsoft in 1991, and remember RAID fondly. My favorite part back then (probably running on Windows for Workgroups): when you minimized the program back to its desktop icon, the icon animated for a few seconds, showing a can of bug spray firing on a small flying bug, which dropped to the ground.
- lejohnny 7y ago
  For green-field projects (new projects/apps), you always had bug #1: "[Insert project codename] doesn't work. Severity: 1. Priority: 1." Always interesting to read some of the bug reports; some of which could meander off-topic in interesting ways.
SlowRobotAhead 7y ago
> The database was written back in the days of 16-bit computing, so naturally it had a limit of 32,767 bugs I know it’s a nitpick; but no, that is not natural to me at all. You can’t have a negative bug or would store it in list with negative indices. So using signed makes no sense to me. Sometimes I get really confused why signed shows up in places it doesn’t belong.
- dragonwriter 7y ago
  > Sometimes I get really confused why signed shows up in places it doesn’t belong. Because in the absence of convenient sum types, you end up using a simple type with sentinel/special values so often that anything where the main value is logically non-negative (or strictly positive) but you don't have a clear reason to never need special values is done with a signed type where negative (and possibly zero) values are reserved or assigned to special uses.
- afiori 7y ago
  It is the same reason the floating point standard loves NaN, exceptional "invalid" values allow you to encode recognizable extra information for error codes or error handling. It is bug prone, but also quite lightweight and flexible.
tracker1 7y ago
It's often the simple things, not meant to last long, but work well that live the longest.
martijn_himself 7y ago
I'm sure RAID was much more usable than some of the ITIL-inspired monstrosities some of us have to deal with.
dmix 7y ago
> Mind you, that doesn’t mean that things have been stable, because the name of the service changed from Visual Studio Online to Visual Studio Team Services, and then again to Azure DevOps Services. That's the most Microsofty sentence ever. It summarizes their allegiance to ever changing marketing goals over simplicity and consistency. Even for something like a bug tracker.
- Avalaxy 7y ago
  Before it was called Visual Studio Online it was called Team Foundation Server. To make things even more confusing, there is now another product called Visual Studio Online, which is a completely different thing (it's a cloud IDE) https://visualstudio.microsoft.com/services/visual-studio-online/ https://visualstudio.microsoft.com/services/visual-studio-on....
FckMoz 7y ago
Microsoft... always around for some lame jokes :D
barrkel 7y ago
Borland's bug tracking tool for Delphi was also called RAID. It used the disconnected data set and resync technology that was part of Delphi itself, which was handy for remote working before always-on internet.
- lt 7y ago
  I wonder if Borland's RAID was inspired on Microsoft's, or just the same pun.
DannyB2 7y ago
Isn't RAID a way of storing all of the zero bits on one drive, and all the one bits on the other drive? That makes replacement of a bad drive much easier.
grillvogel 7y ago
im a CMVC man myself
twhitmore 7y ago
Is it just me, or does this seem terrible? Lack of a stable business key & limiting key size to 4.5 digits just seems terribly lacking in any competent database practice. I was building ISAM database applications for small business in the early nineties, and we used 6 digit keys.. and an index to access records by. I'm sure Raymond Chen is a nice guy, but this just makes me think of a retard stabbing his cheek when trying to eat with a fork. (Dirty Rotten Scoundrels movie.)
- dang 7y ago
  Yikes, please don't post like that last bit here. I get that you probably meant it lightheartedly, but it does not come across well. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

399 points by soheilpro 7y ago

I 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 bug spray. (And obviously we used the logo from the punk band...)

airstrike 7y ago
I feel like I'm watching an episode of Halt and Catch Fire. Thanks for sharing!
- ShamelessC 7y ago
  Such a great show. I wish more people knew about it.
  - jjordan 7y ago
    Never heard of it, but as a tech nerd from the 80's it sounds awesome. Will definitely check it out.
    - unnouinceput 7y ago
      1st season is very good. Rest are crap.
      - noir_lord 7y ago
        A bit unfair, first season is amazing, the rest are merely very good - it’s a brilliant show overall though.
        dagw 7y ago
        Really depends on what you want in a show. If you came in expecting a show about people designing computer and solving hard and interesting technical problems along the way you will be become more and more disappointed as the show goes on and focuses more on the characters personal problems and whether or not they get married/divorced/sleep with each other.
        droidist2 7y ago
        Yes, it's very similar to Mad Men in that respect.
        unnouinceput 7y ago
        There is no comparison to Mad Men. MM was good all the way to the final season, with both professional view of advertising world and personal growth of characters. Was perfect balance. HaCF only had that in 1st season, in rest it lost its balance becoming a soap opera, which I can't stand.
        aguyfromnb 7y ago
        >focuses more on the characters personal problems and whether or not they get married/divorced/sleep with each other. This is an unfair summary. There might be a divorce (does no one in the tech world get divorced?), and a relationship (that starts in Season 1, Episode 1 and is a driver of the plot), but it is nowhere near about "who sleeps with who". The show has good character development; would you rather the people not do anything in life, over the 15 or so years the show covers? Halt and Catch Fire is great television that loosely follows the technology arc/personal computing age from the early 1980s through the 2000s. It has great acting and characters, including two strong female leads. If you go in thinking it's going to be about people sitting around "solving hard problems on computers", yes, you will be disappointed. There are coding screencasts for that. It's a shame to discourage someone from watching wonderful television about a subject we're all here for.
whalesalad 7y ago
Everything about this story is awesome, especially the fact that you used the same logo from the punk band.
OakNinja 7y ago
Fun fact, one of Sweden’s most influential music- and culture journalists was being interviewed on national television about a weird documentary wearing a pink “Pink Flag” t-shirt with a modified Black Flag logo. Beyond meta.
- OakNinja 7y ago
  The t-shirt was all pink of course.
- brigandish 7y ago
  Is that a clever way of referring to Black Flag at the same time as Wire's Pink Flag?
  - OakNinja 7y ago
    That’s how I interpret it. I actually asked him on Twitter an hour ago - I’ll keep you posted :)
- joachimma 7y ago
  Lokko or Strage?
  - OakNinja 7y ago
    Strage!

shepwalker 7y ago

Oh lord, product studio. Back in 2013 the preferred method of filing workitems for a given "wave" was to load this spreadsheet, do weiiird formatting, and indentation, type up all the workitems you foresee for the next sprint and then press a magic "send to product studio" button." God help you if you messed up some of the nesting or wanted to reorder anything - honestly I would just wipe it clean and start from scratch. Ironically my team just finished a product called RAID that was designed to kill bugs in product studio and move them to DevOps. There are still pockets of teams that use Product Studio within Microsoft - the sufficiency gap is real - but they're the overwhelming minority now.

mc32 7y ago
Sounds like the product could have been named FLIT, given the finicky nature. [1]https://en.wikipedia.org/wiki/Flit_gun https://en.wikipedia.org/wiki/Flit_gun
asveikau 7y ago
I had absolutely zero problems with product studio when I used it from 2008-2011. It was a very 1990s style MDI application, somewhat representing the peak of win32 ux design, short and to the point, and as long as the servers were happy it "just worked".

lifeisstillgood 7y ago

>>> they might have been too scared to write it. When looking back on the origin of RAID, one of the original developers confessed, “It really wasn’t made to last that long. Sorry!” This speaks to me - too many times we think we need clever architecture and well thought out methodologies and ... the most useful tools are a mix of inspiration and timing and luck. Had the developers stopped to plan they would have built something with over 16 bits of primary key - and also made a hundred other "improvements" that would have destroyed all the value MS got out of it. There is a point in this - it I am not sure I know what it is.

hermitdev 7y ago
> Had the developers stopped to plan they would have built something with over 16 bits of primary key While true, this was in the 16-bit, Windows 1.x era. Also the ~640kb of RAM era (disks also werent that big either, DOS (v3.x) around that time only supported 32 MB partitions). Not sure which version of DOS Windows 1.0 ran on, I didnt use windows until v3.11 for Workgroups. A 32-bit primary key would likely have been seen as wasteful (not that I'm excusing it) and impractical, because you could likely never practically store more than 64k records on a PC of the day (and even if you could, you wouldnt have an disk left to do anything else).
- gdwatson 7y ago
  He didn’t say which platform it ran on. Was Microsoft still using Xenix internally at the time?
  - exikyut 7y ago
    Yes, for a time Xenix was used for some proportion of internal development, IIRC for DOS. I think I read that on here somewhere. I unfortunately don't have a citation. Need to get a time machine to take me to whatever point in the future I sort out my bookmarks ._.
lozaning 7y ago
On the other hand, temporary fixes are often the most permanent kind.

benschulz 7y ago

I'll take any opportunity to mention John Browne's "The Bug Count Also Rises"[1], which contains the line "The RAID is huge with bugs", referring to Microsoft's bug tracker. It was previously submitted to HN[2]. [1]: http://www.workpump.com/bugcount/bugcount.html http://www.workpump.com/bugcount/bugcount.html [2]: https://news.ycombinator.com/item?id=2740452 https://news.ycombinator.com/item?id=2740452

dmix 7y ago
What a poetic (and a little depressing-in-a-good-way) comment. I remember various times of my career being a glorified bug tracker. It's a bad mode to get trapped in with no forward progress. https://news.ycombinator.com/item?id=2740626 https://news.ycombinator.com/item?id=2740626

m4rtink 7y ago

And if you have disks in RAID a bug in it kills your data instead. ;-)

glangdale 7y ago
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.
mirimir 7y ago
I was wondering about that myself.

jkcorrea 7y ago

Fun 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 and confusing UI :). edit: Though to be fair, the team maintaining it has made massive strides recently to completely revamp the UX which is no small feat given such a wide range of business critical use cases.

saagarjha 7y ago
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.
- jkcorrea 7y ago
  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.
  - daniel_reetz 7y ago
    It was torture. Bimodal is right.
  - lilyball 7y ago
    The UI was old and crufty and it was a pain in many ways to work with. But I really miss it because it’s still better than any other issue tracking system I’ve ever used.
    - PeterStuer 7y ago
      Can you elaborate on what made/makes it better?

khy 7y ago

It's a weird, nice feeling watching your software in use well beyond it's planned - or more frequently, assumed - obsolescence.

hermitdev 7y ago
What ammuses me is looking at some of the hard-coded "end of time" dates at previous employers. Instead of using null as an unbounded upper bound (because nulls are hard /s), there are hard coded "end dates". One was 2032-12-31, another 2037-12-31 and usually 9999-12-31. Obviously, these all have problems, especially when used in finance. 2037 makes sense, because 2037 is the year that 32bit linux overflows. 9999 also makes sense. At least none of us will be around, so it's some future generation(s) problem. The 2032 one made no sense to me, and I was never able to get a justification.
- kaibee 7y ago
  Now that it's 2020, I've been looking for a new year to think of as "the future". 2040 seems too obvious and maybe too far away to really imagine, what just add 20 years? Boring. I think I'll take 2032.
  - Paul-ish 7y ago
    2049, for the year the blade runner sequel is set in.
  - JadeNB 7y ago
    The year 2525—if man is still alive.

m0zg 7y ago

Google'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/ 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.

saagarjha 7y ago
I think the Material UI is new, it used to look a lot different when I used it externally (back in 2017).
- q3k 7y ago
  Yes. You can still access the old UI. https://q3k.org/u/0640089a352229b87077f05752ea415abd19e762889b9d8c346c57b8db863bd4.png https://q3k.org/u/0640089a352229b87077f05752ea415abd19e76288...
fred256 7y ago
Buganizer was preceded by BugsDB if I recall correctly
hyperrail 7y ago
> 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. Filing a bug in another Microsoft product has been technically easy for a long time. It's true that each product team has their own Product Studio database or Azure DevOps organization, but Product Studio gives you a listing of all PS databases company-wide, and I think you can get the same thing with AzDO. And in both, you can open a bug in any work item tracking database you have write access to. To the extent that you cannot/could not touch bugs or sources for other Microsoft products than the one you work/worked on, that was more a feature of Microsoft's confidentiality policies and corporate culture than of our tools. That is, people in the Windows organizations had access to Office's Product Studio DB or master source repos only if they were specifically delivering features for Office, and vice versa. That attitude is mostly gone now. Since 2013, everyone working on product R&D has had access to most other products' resources, and (IMO) almost no one tries to jealously guard their code against "outsiders". There are still different bug databases for each Microsoft product, but you have permissions to read all of them by default. Exceptions to this general openness and transparency are largely limited to consumer hardware products (Surface, Xbox) which remain very tightly controlled against leaks. (Above is based on my personal experience working for Microsoft in the start and end of the last decade, with a gap in the middle.)

bentcorner 7y ago

Sometimes 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.

hermitdev 7y ago
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".
- sitkack 7y ago
  Train a spam filter and use a commit hook, in Perl.
bitwize 7y ago
That is because Industry Best Practice these days is to use JIRA, which lumps bugs in with stories and spikes and other agileshit. They must be planned, prioritized, and pointed alongside all the other work. Ceremonies must be done. The idea that they are defects, and that tracking them and their fixes specially is important, tends to be lost.
hyperrail 7y ago
Fossil (https://www.fossil-scm.org https://www.fossil-scm.org ) has an interesting approach to this problem - integrate bug and work item tracking, project wikis, and source control, but make them all distributed, so that there is not a single master copy of the bug database or the docs wiki. It attempts to solve both the cultural challenge (bugbase written by a different company/team from the source control, imposing 2 different styles on you) and the technical one (bugbase and source control don't talk to each other, and so bugs and checkins are not linked).

abiogenesis 7y ago

> 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.

lilyball 7y ago
Presumably the archive projects are read-only and therefore once a bug goes into the archive project it never moves again.
- deleted 7y ago
  [deleted]
SifJar 7y ago
I assume it'd be a chain e.g. db 1 - issue 3141 db 2 - issue 12 (originalid:3141) db 3 - issue 4 (originalid:12) etc.

macjohnmcc 7y ago

I remember using RAID when I worked at Microsoft from 1993-1996

bearer_token 7y ago

Who wants to celebrate the 18th anniversary of the oldest open Jira ticket with me? https://jira.atlassian.com/browse/JRASERVER-161 https://jira.atlassian.com/browse/JRASERVER-161

smacktoward 7y ago

The one thing all long-lived systems have in common: nobody ever intended them to be long-lived systems.

mitchty 7y ago
There's nothing more permanent than a temporary solution.
jedberg 7y ago
The quick and dirty Perl deployment system I built at reddit lasted nine years. Five years after I left. I definitely never intend it to last that long.
- meddlepal 7y ago
  Even better is when a long-dead system is suddenly resurrected and repurposed for another project. I had a friend at a company I left tell me they were un-mothballing a cancelled platform (killed at the time by an unfortunate acquisition) and deployment system I built several years ago because it was needed again. The whole thing was pretty janky because it was barely past prototype but fairly functional. I wished him good luck and told him to find a new job, because there be dragons. He took the advice eventually, but I did hear they got it up and running again, with some pain. Apparently it is out there chugging along doing its thing once again.
- smacktoward 7y ago
  My father wrote a dBase application forty years ago that, to his amazement, is still in use in some places today. Inertia is a hell of a force.
  - twhitmore 7y ago
    It probably has more digits for the primary key than the MS bug tracker originally mentioned. Sigh.
- jnothing 7y ago

naringas 7y ago

it killed them dead by means of tracking and keeping them in an inventory...

ikeellis 7y ago

As an independent dev team working with Microsoft Games in 2002-2003, we used RAID to ship Rise of Nations. It was great! Rockin' fast compared with any web tool now and batch operations were near instant. Sadly it was utterly insecure for remote use and it went away after that game.

Infernal 7y ago
I loved Rise of Nations! Mind sharing which bits you worked on?
- ikeellis 7y ago
  Single player campaigns

zestyping 7y ago

The bug puns were everywhere! When I started working at Industrial Light and Magic in 1998, there was no bug tracker in regular use. I ended up building a bug tracker in Python called "Roundup" (inspired by a program by Alan Trombla, who came up with the name). To create the thinnest veneer of plausible deniability in case the bug spray lawyers came after us, the icon was a little spinning GIF animation of a cowboy on a horse, lasso curled in the air. I only stayed at ILM for two years, but Roundup remained still in use as the ILM software department's main issue tracking system long after I left, at least 6 years later. It was one of the early issue tracking systems that made it easy to subscribe to any issue, so you'd get e-mail notifications whenever the issue was updated. The issue identifiers were numbers prefixed with a code to indicate the affected software project, like "REN003" for a bug in the rendering system. Three digits, of course, because I could hardly imagine that a single project could ever have more than a thousand bugs! I remember that along with statuses like "in progress" and "done", we had a status I've never seen anywhere else: "cbb". As in "done, but could be better." What optimistic software engineers we were back then!

rconti 7y ago
CBB reminds me of the pieces of hardware I've labeled as "maybe bad". Only to run across 2 years later, and find myself wondering "who was this 'future me' that I envisioned might be interested in an ethernet card that exhibits flaky behavior under high load when bonded?"
- Anthony-G 7y ago
  Been there and learned that lesson! Let's waste future me's time by having them figure out in what way the hardware might be bad.
- exikyut 7y ago
  Well, if it just corrupts packets and doesn't (make the (driver|kernel) crash|bring the link down completely|confuse PCIe so badly the PCH hard-resets) you could use it to build a resilient UDP (or even TCP) packet retransmission algorithm. Not kidding, the results would probably be drop-in usable for cellular/satellite/microwave/etc links, and spotty WAN in general.

vector_spaces 7y ago

The late Joe Armstrong described the similarly minimal Erlang issue tracking system in this excellent post about MVPs https://joearms.github.io/published/2014-06-25-minimal-viable-program.html https://joearms.github.io/published/2014-06-25-minimal-viabl...

KasianFranks 7y ago

No you did not.

sitkack 7y ago

I loved RAID. Lightning fast, so fast that speed was its own quality.

sitkack 7y ago
Of all my comments, this is oddest thing to downvote! Is RAID bad now?
- marvy 7y ago
  seek not to comprehend the downvoters, for it is written: it is simpler to predict each gust of wind in a storm, than to explain even a single downvote or something
  - sitkack 7y ago
    Thanks marvy, this made me smile.
    - marvy 7y ago
      :)

jdsully 7y ago

Product Studio, RAID's replacement was great. I really didn't like the transition to TFS.

badsectoracula 7y ago

> Office cloned the source and built their own custom version I found this bit amusing considering that (IIRC) the Office team also had their own C compiler :-P

philiplu 7y ago

I started at Microsoft in 1991, and remember RAID fondly. My favorite part back then (probably running on Windows for Workgroups): when you minimized the program back to its desktop icon, the icon animated for a few seconds, showing a can of bug spray firing on a small flying bug, which dropped to the ground.

lejohnny 7y ago
For green-field projects (new projects/apps), you always had bug #1: "[Insert project codename] doesn't work. Severity: 1. Priority: 1." Always interesting to read some of the bug reports; some of which could meander off-topic in interesting ways.

SlowRobotAhead 7y ago

> The database was written back in the days of 16-bit computing, so naturally it had a limit of 32,767 bugs I know it’s a nitpick; but no, that is not natural to me at all. You can’t have a negative bug or would store it in list with negative indices. So using signed makes no sense to me. Sometimes I get really confused why signed shows up in places it doesn’t belong.

dragonwriter 7y ago
> Sometimes I get really confused why signed shows up in places it doesn’t belong. Because in the absence of convenient sum types, you end up using a simple type with sentinel/special values so often that anything where the main value is logically non-negative (or strictly positive) but you don't have a clear reason to never need special values is done with a signed type where negative (and possibly zero) values are reserved or assigned to special uses.
afiori 7y ago
It is the same reason the floating point standard loves NaN, exceptional "invalid" values allow you to encode recognizable extra information for error codes or error handling. It is bug prone, but also quite lightweight and flexible.

tracker1 7y ago

It's often the simple things, not meant to last long, but work well that live the longest.

martijn_himself 7y ago

I'm sure RAID was much more usable than some of the ITIL-inspired monstrosities some of us have to deal with.

dmix 7y ago

> Mind you, that doesn’t mean that things have been stable, because the name of the service changed from Visual Studio Online to Visual Studio Team Services, and then again to Azure DevOps Services. That's the most Microsofty sentence ever. It summarizes their allegiance to ever changing marketing goals over simplicity and consistency. Even for something like a bug tracker.

Avalaxy 7y ago
Before it was called Visual Studio Online it was called Team Foundation Server. To make things even more confusing, there is now another product called Visual Studio Online, which is a completely different thing (it's a cloud IDE) https://visualstudio.microsoft.com/services/visual-studio-online/ https://visualstudio.microsoft.com/services/visual-studio-on....

FckMoz 7y ago

Microsoft... always around for some lame jokes :D

barrkel 7y ago

Borland's bug tracking tool for Delphi was also called RAID. It used the disconnected data set and resync technology that was part of Delphi itself, which was handy for remote working before always-on internet.

lt 7y ago
I wonder if Borland's RAID was inspired on Microsoft's, or just the same pun.

DannyB2 7y ago

Isn't RAID a way of storing all of the zero bits on one drive, and all the one bits on the other drive? That makes replacement of a bad drive much easier.

grillvogel 7y ago

im a CMVC man myself

twhitmore 7y ago

Is it just me, or does this seem terrible? Lack of a stable business key & limiting key size to 4.5 digits just seems terribly lacking in any competent database practice. I was building ISAM database applications for small business in the early nineties, and we used 6 digit keys.. and an index to access records by. I'm sure Raymond Chen is a nice guy, but this just makes me think of a retard stabbing his cheek when trying to eat with a fork. (Dirty Rotten Scoundrels movie.)

dang 7y ago
Yikes, please don't post like that last bit here. I get that you probably meant it lightheartedly, but it does not come across well. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html