We called it RAID because it kills bugs dead
devblogs.microsoft.com
devblogs.microsoft.com
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.
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!
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?"
Not kidding, the results would probably be drop-in usable for cellular/satellite/microwave/etc links, and spotty WAN in general.
I'm sure bugzilla is older though.
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.
To judge from the outside, one of its features is that it makes it super easy to ignore years-old and highly multiply submitted bugs.
I can't believe getting out of an amp page takes a copy paste on iOS.
The frustration streams from the human side, not the bits
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.
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).
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 ._.
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.
https://q3k.org/u/0640089a352229b87077f05752ea415abd19e76288...
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.)
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.
[1]: http://www.workpump.com/bugcount/bugcount.html [2]: https://news.ycombinator.com/item?id=2740452
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.
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.
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-on....
I definitely never intend it to last that long.
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.
Inertia is a hell of a force.
Always interesting to read some of the bug reports; some of which could meander off-topic in interesting ways.
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.
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).
https://joearms.github.io/published/2014-06-25-minimal-viabl...
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.
I found this bit amusing considering that (IIRC) the Office team also had their own C compiler :-P
That makes replacement of a bad drive much easier.
I wonder what happened if a bug was carried over for 2 or more databases.
db 1 - issue 3141
db 2 - issue 12 (originalid:3141)
db 3 - issue 4 (originalid:12)
etc.
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.
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.
or something
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.)