Microspeak: bar check

A bar check sounds like the sort of thing you receive at the end of a long evening of drinking, but that's not what a bar check is.

Among the things that happen at ship room meetings is reviewing each bug that has a proposed fix and deciding whether to accept or reject the fix.

Another thing that happens at ship room meetings is the bar check: The person representing the bug describes the issue and what is known about it so far and asks for a preliminary assessment from the ship room as to whether this is the sort of bug they would approve if a fix were available, in other words, whether it meets the bug bar. If the answer is No, then there is no need to go to the effort of developing a fix for it right now, since you know it would get rejected anyway.

Comments (15)
  1. Joshua says:

    If the fix isn't likely to have nasty consequences I usually develop it anyway. Of course I don't have to worry about somebody poking into my memory space (which doesn't mean I don't have to worry about someone depending on a bug).

  2. Anon says:

    The equivalent of refusing to fix a structurally flawed I-Beam in a skyscraper because it would cost too much money to get to it for the repair.

    When the building tumbles down around it, you'll wish you'd fixed it, but no one will ever have to take any responsibility for a terrible decision, so it doesn't matter.

  3. Brian says:

    More like refusing to repaint a stair railing because it would delay opening the building.

  4. Joshua says:

    More like discovering that the wheelchair ramps are too steep on one side of the building.

  5. It seems a huge lot of things fail bar check in Microsoft

  6. Chris says:

    @Fleet Command

    I'm sure they do. Any substantial piece of software probably has hundreds of open bugs raised against it, ranging from crashes that impact some subset of users on a regular basis, to some undesired behavior which a tester found can occur if you poke it just right but users aren't running into a lot, to an icon in some out-of-the-way dialog being slightly misaligned. But if you never shipped because there were open bugs, you'd never ship at all (and features and bug fixes you haven't shipped are no use to anyone), while if you don't prioritize, the icon alignment might be fixed instead of the crashes.

  7. 640k says:

    Apparently both features and bugs starts at -100 for lazy people.

  8. @Chirs: I think you are right; except right is a tricky word. Three pieces of criticism often leveled against Microsoft is being slow, failing to properly interpret public feedback and not fixing bugs. In short: Instead of fixing the bugs and shipping on time, Microsoft wastes time on nothing tangible. (Oh, and Microsoft likes it huge too!)

    I was one of the beta testers of IE7. I distinctly remember Firefox 2 started out later and came out earlier. I had this perception of "piece of junk" from Firefox, so when I saw version 2, my jaw dropped. Basically, it could match toe-to-toe with IE7. But when CNET released a comparison review of both with a boxing theme, I still shouted "Biased!"

  9. Mike Dimmick says:

    @Joshua: In the circumstances where this is even being discussed – glide path to release after all features are signed off, which is when 'ship room' goes into effect – then you should be focused on the bugs that are blocking release: those that pass the bar check. You can work on your bug that didn't pass the bar check once the release is out. The team don't want to take the risk that your bug fix breaks something critical.

    @Fleet Command: My hope is that the April 2014 Windows 8.1 Update is a sign that such bugs are actually being actively worked on by the product team with the intent of releasing them as an update to the current release, rather than being deferred to the next release, which might happen years later and bring with it other radical redesigns. Previously, only bugs and Design Change Requests raised by customers and OEMs went into service packs (excepting one-offs like Windows XP SP2). The work on them was typically done by Windows Sustained Engineering, who have apparently renamed themselves Customer eXperience Engineering (CXE), to keep them from distracting the product team from the new product, but that actually means the product team are quite insulated from the consequences of decisions made in the last cycle.

    Of course if you do encounter such a bug, or a mis-designed feature, and you really can't tolerate it, you could always raise a support ticket (you will need to pay for a support incident or use a gratis one included as part of however you licenced the software or your company's support contract).

  10. Klimax says:

    @Mike Dimmick:

    It started with Windows 7 (at latest with W8) and released quite few non-security bugfixes.

  11. Joshua says:

    @Mike Dimmick: I seem to be in the unique place of every support request in the past 2 years has resulting in my money being refunded (or not charged) and the problem left unfixed.

  12. Anon says:


    I assure you, you're not in a unique place there!

  13. cheong00 says:

    Talking about Win8.1 update 1, they really should have fixed the bug in typing Chinese in DirectX environment. Unable to select every 1 word out of 10 is just not acceptable. This is the major factor that blocks Win8.X upgrade in Chinese speaking reign.

    Okay I should have talk about this in Michael Kaplan's blog, but since his blog is down, hope that he can see this.

  14. voo says:

    @Anon: Presumably just hyperbole and/or trolling, but still: Clearly the thing you're describing is a serious *security* bug and I don't think the bar gets ever so high that MS would ship an OS with a known remote code execution exploit around..

  15. Blast from the past says:

    This topic reminded me of the old fourstones column, particularly:


Comments are closed.