There are no bugs in the I/O manager

Mark Zbikowski told me a story from the early Windows NT days.

He found a race condition in the file system code and went to see the lead developer for the I/O subsystem.

"There are no bugs in the I/O Manager," the developer proclaimed.

Mark walked through the scenario to demonstrate the problem.

The lead developer went to his editor and typed furiously for two or three minutes, ending with a theatrical punch of the Enter key.

And he turned to Mark and proclaimed, "There are no bugs in the I/O Manager."

Comments (17)
  1. florian says:

    I wish I were as brave as Mark Zbikowski – but whenever I try, there will be two new bugs …

    1. florian says:

      Aw, I mean as brave as the I/O subsystem lead developer – see?

  2. Paul says:

    I hope this attitude changed and that, if there was a bug, it was fixed.

    1. Paul Veitch says:

      I think that was the two or three minutes of typing. i.e. he fixed the bug, so his statement was “technically” correct

      1. cheong00 says:

        Or there are cases why you add a few checks to verbosely display the execution state (possibly these are the days before the concept of unit tests exists), run the code and see the internal state matches his expectation, and confirmed that there’s indeed no bug.

        This could also be fitted in the 2-3 minutes time frame.

    2. Antonio Rodríguez says:

      In fact, when he proclaimed “There are no bugs in the I/O Manager”, he was confirming that the one and only existing bug had been squashed. If only half the developers took as seriously bug fixing as this one, six billion people would live better…

  3. camhusmj38 says:

    Is the race condition his initial proclamation that there are no bugs in the I/O manager? Bugs being fixed before their reporting suggests a race condition of some sort – possibly in the space-time component of the universe.

  4. Justin says:

    I guess Mark hit a race in the I/O Manager Developer.

  5. AberAber says:

    I’ve found with experience…the piece of code you are most confident in and thus spend the least time checking out…are almost always where bugs crop up to.

  6. Erik F says:

    This reads like one of the koans from the Jargon File. I approve.

  7. John Styles says:

    Over the years I have come to the conclusion that this is a hard to bridge philosophical issue, ‘does a piece of software have the property of bugginess independent of the existence of known bugs?’. To me, the answer is clearly yes, but I have worked with a couple of people at various points who clearly have the attitude that program X has N unfixed bugs in the bug tracking system whereas program Y has M with N>M, therefore X is buggier, notwithstanding that Y has had 10 times more fixed. If M = 0 then Y is ‘bug free’.
    Questioning / arguing made me sure that they were both perfectly sincere in this belief.

    1. Scarlet Manuka says:

      I don’t think anyone would dispute that any piece of software might have as yet unknown bugs. But there’s not much you can do with that from a practical perspective. All that’s actionable are the bugs you know about, so it’s reasonable to consider a program bug-free if it has no known bugs.

      Besides, it is *possible* that the program really is bug-free. There’s no evidence against it (or that would be a known bug), so it’s only Bayesian statistics that makes you believe there probably is a bug there.

      Back to the article though – it’s a nice story, but I hope at least 30 seconds of that typing was some sort of test…

      1. Alex Cohn says:

        Unknown bugs are quite actionable. You run all kinds of antivirus and firewall software to mitigate yet undiscovered bugs. You wrap the app in a sandbox. You establish monitors and watchdogs.

  8. Paul Z says:

    A traditional method of finding race conditions in operating system code is to go to the top of some function and start typing a comment:

    /* This can’t race because

    and then you invariably find the race.

  9. Geoffrey Armstrong says:

    Maybe the typing was an email to HR?

  10. gast128 says:

    I dislike this kind of arrogance. If you have sufficient self-knowledge one should know that software engineering is too difficult for humans except for the most simple cases.

    1. Zenith says:

      Arrogance? I’ve heard poor developers call it that. Some of us actually care about our craft though.

Comments are closed.

Skip to main content