3 ms·

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

by 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.)
RandallBrown 7y ago
I remember when I first started at Microsoft, I found some bug in some product and thought "I should file a bug with them" Turns out there was no easy way to do that. I ended up emailing some person from the team I found in the GAL (I think that's what they called it?) and they weren't helpful or appreciative. Never did that again.
- m0zg 7y ago
  I don't know how it is now, but you've just described every single well-meaning starry eyed fresh Microsoft employee in the 00s and likely before. The fact that management did not see how fucked up this was is a condemnation of the Microsoft company culture of that period. Again, don't know how it is now. I turned in my blued badge well over a decade ago.

by m0zg 7y ago

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

RandallBrown 7y ago

I remember when I first started at Microsoft, I found some bug in some product and thought "I should file a bug with them" Turns out there was no easy way to do that. I ended up emailing some person from the team I found in the GAL (I think that's what they called it?) and they weren't helpful or appreciative. Never did that again.

m0zg 7y ago
I don't know how it is now, but you've just described every single well-meaning starry eyed fresh Microsoft employee in the 00s and likely before. The fact that management did not see how fucked up this was is a condemnation of the Microsoft company culture of that period. Again, don't know how it is now. I turned in my blued badge well over a decade ago.