A possibly unbeatable record for the shortest amount of time between an email message and its resend

I occasionally bring up the issue of people who ask a question and then repeat the question, especially people who repeat the question with some impatience. At the time, the record for the shortest time between the message and its repeat was eight minutes.

But I think I have something unbeatable.

From: X
To: ABC Team

I hit this crash in ABC. Can somebody take a look at it?

A half hour later, somebody replied:

From: A
To: X, ABC Team

This looks like the problem is really in the DEF component. You should have the DEF team look at it.

Person X waited a few hours, then got impatient.

From: X
To: DEF Team

Any update on the attached issue?

Notice that person X's request for an update was the initial contact with the DEF team. One way of looking at this was that the time between the message and its resend was zero seconds. The only way to beat this, I guess, is to send the repeat message before sending the original.

But if you look at it another way, this is in fact unbeatable: Since there was no earlier message, the time between the message and its resend is actually NaN.

Comments (25)
  1. steven says:

    Some people I know use this trick to get feature requests through. They will ask for updates on something as if it should have been completed long ago, when it is, in fact, the first time it is ever mentioned. This seems like an attempt to circumvent the process of actually deciding whether something should be implemented at all.

  2. In C++ that would probably be undefined behavior more than NaN, specified by the usual clear rules of the Standard:

    [ Any expression involving involving a non-sequenced read of a possibly cv-qualified prxπ$ç-value ( referring to an implementation-defined timestamp of a non-sent "email" (as specified in ISO/IEEC/YACC/AAPL+5% RFC753) invokes undefined behavior. An implementation may emit diagnostics, but that renders the programmer's mood ill-defined. (Forward references: "Sequenced expressions" 5.12.52, "Confusing arrays rules" 8.1.25, "CV-madness" 3.5.2) ]

  3. Ben says:

    Possibly they simply thought the original reply "You should have the DEF team look at it. " had been CC'd to the DEF team. I would have CC'd them. So I might not think to actually check whether they did or not, just assumed they did because I would have.

  4. Rick C says:

    Matteo Italia, there's some other weirdness in your quote, like non-English characters and "AAPL+5%".  "[R]enders the programmer's mood ill-defined" doesn't seem like wording that belongs in a spec, either. :)

  5. Falcon says:


    Good point, however, if the ABC team member had CC'd the reply to the DEF team, I would hope that they would state this, rather than suggest that Person X should contact the DEF team. Of course, one's hopes and expectations may not match others' actions.

  6. Phil McKerracher says:

    This also looks like a possibly unbeatable record for bad communication and management. I don't know what the relationship between X and the other teams is exactly (and neither do they, it appears), but X seems to be in some sense a customer (possibly internal) whose workflow has been severely disrupted. For some reason X expects ABC to solve their problem with some urgency. Are they just asking a favour or is there some sort of real or implied contract? Is X expected to do a certain amount of investigation before reporting an apparent crash? If so, does X know this? It's not clear why they expect ABC to do anything at all.

    Anyway, ABC rejected this request without "taking ownership" of the problem. Do they really expect X to find the correct team by trial and error? Basically ABC are saying "you didn't ask the right question so we're not answering, try again". How helpful. What, if anything, should X have done differently in their initial contact? It's not clear from this example.

    ABC seem to have done at least some investigation and want to pass the buck to DEF but don't. Why would they not inform DEF? Surely there's a significant risk that X was right and the problem will bounce right back. Or that DEF will bounce it to team GHI. ABC are behaving as if they're perfect and the rest of the world are idiots. How unusual (not).

    I'm guessing someone is measuring team productivity and no-one is measuring customer satisfaction. Am I right?

    [Imagine you're an electrician asked to investigate why a circuit doesn't work. You figure out that the circuit is fine. The problem is that the appliance plugged into it is not working. You say, "This is not a circuitry problem. You need to talk with the service department for your appliance." You the electrician do not know the service department telephone numbers for every appliance manufacturer. You're leaving the customer to do the follow-up using their own contacts. -Raymond]
  7. Joshua says:

    How to spook out another engineer:

    Engineer is getting crash in Word when trying something that uses Word automation. Engineer asks you for help. Press debug when the "Send to Microsoft" message comes up. Look at the disassembly. 30 seconds later, say "I see the problem." Its especially funny when the disassembly says that IP is in unmapped memory.

    He actually pressed "Send" a couple of times. (It was the newest version of Word at the time.) I can imagine the MS team having one heck of a time trying to figure that crash out in the crash logs.

    That would have been murder for us if a customer hit it first.

  8. Bob says:

    @Phil & Raymond:  I think the difference in response is related to how we view the DEF component as related to the ABC software. How user-visible and user-serviceable is DEF?

    Raymond is treating DEF as if it were akin to a browser plug-in which the user had separately installed and which turned out to be not so compatible.

    Phil is treating DEF as if it were the browser's renderer.  I.E. something that is an integral part of the software installation and which has no visibility to the end-user.

    Of course, if this happened within Microsoft (something not stated, but perhaps implied) and person "X" was a technical person and person "A" gave some details not shown about why the problem was in DEF. Then perhaps it makes sense to assume that person "X" should have made the contact.  Otherwise, person "X" has no argument to give to the DEF team that the problem is in their component other than "Person 'A' said so but gave no reason".

  9. varun says:

    I think it's a cultural thing. If it's not my problem, but I know whom to direct it to, I usually reply "this is an issue for so-and-so, CCed above" and add the responsible party to the CC chain. I think X simply didn't notice that DEF wasn't CCed, seeing as A specifically identified DEF as the responsible party. I consider CCing the relevant team responsible passing of the buck :)

  10. Bob says:

    As Phil alludes to here and Raymond discusses in the attached articles, the SLA is relevant. The post does imply that there is no SLA involved. If there were a SLA, the person "A" would have opened a ticket instead of sending a message.

  11. Destroyer says:

    I know exactly why this annoys you – at the end of the day person X is just batting emails around without putting any effort or thought into the process themselves. This sort of behaviour can often sum up their efficiency and capacity at doing their job, it's exactly what an organization could do without. They are probably very good at using the Reply-All button and even better at the Forward one!!

  12. Zan Lynx' says:

    Destroyer, there isn't enough information here to decide that X is not putting in effort.

    The situation might be that X is an engineer working on XYZ when he hits crash bug in ABC's component. Should he waste a lot of his time figuring out ABC and DEF's bug? No, he should report it and move on. Possibly even basic bug data collection is a waste of time. There have been many times I run into a bug and the other team tells me it is a known problem before I even get done describing the symptoms.

    Now, I find myself doing this (tracking down bugs in someone else's library) all the time when working with open source software but I really shouldn't.

  13. Anon says:


    Except they didn't create a Bug/Ticket. They created an email. Had they created a Bug/Ticket, ABC could have simply reassigned it to the DEF team.

    If there's no Bug/Ticket, there's no problem. If there's no problem, there's no reason for ABC to even bother responding to the email. ABC went above and beyond here.

  14. (the duplicated "involving" in the previous post comes from the fact that I'm quoting a free *draft* of the standard, since I'm not rich enough to buy the definitive text)

  15. hacksoncode says:

    If you consider the time to be NaN, it simultaneously sets the record for shortest *and* longest gap.

  16. kvleeuwen says:

    Or X, in the meantime, walked over to DEF Team and showed them in person how to reproduce the problem, or he might have explained it during a coffee break.

    The initial contact might have been established without email.

  17. Neil says:

    @hacksoncode: And it manages to do this despite both previous records also being NaN.

  18. Marc K says:

    Perhaps ABC team doesn't want to become the secretary for X, which is a risk if they CC the DEF team.  Plus, they run the risk of seeing the whole thing play out through Reply All.

  19. Anon says:


    Where's your evidence that ABC chose to use DEF, rather than X choosing to use DEF?

    And, as has been mentioned repeatedly, emails are never the correct way to file a bug.

    [Or DEF is an ABC plug-in, so in fact it was DEF that chose to use ABC. -Raymond]
  20. Mark says:

    Brian: my reading is these are teams within Microsoft. In your car company analogy, it's more like someone approaching the assembly line workers about the engine. They've ascertained it's not an assembly problem, so why would they need to get involved further?

  21. Rick C says:

    Indeed, ABC and DEF could even be components in application GHI.  The point is we don't know, so everyone talking about SLAs and how much effort X expended is kind of missing the point, which is that–from what we've seen–X hasn't initiated contact with DEF.  We can't make the assumption that an email X sent to ABC obligates ABC to notify DEF on X's behalf.

  22. Brian_EE says:

    The way I see it, the crash occurred in the program developed by ABC. ABC *chose* to use DEF component in the ABC program, so they bear some level of responsibility to figure out why the program is crashing.

    If ABC wants their program to be robust, then they should have some involvement in ensuring the DEF team fixes the problem, or modify their program to operate without using DEF's component.

    The analogy is going back to the QRS car company complaining that the engine died. You wouldn't expect them to say "We buy the engine from supplier XYZ, go talk to them about it", you'd expect them to handle the problem because they chose to put XYZ engines into the QRS cars.

  23. GWO says:

    Brian: my reading is these are teams within Microsoft. In your car company analogy, it's more like someone approaching the assembly line workers about the engine. They've ascertained it's not an assembly problem, so why would they need to get involved further?

    Right. And the last thing that the assembly team should do is *escalate the problem to the engine team*.  That's what's good practice here. For the assembly worker to say "not my problem" and just stop is extremely unprofessional.

    [You're assuming the assembly team knows how to contact the engine team. -Raymond]
  24. John Doe says:

    You must get outside the box.

    This is actually pretty normal, unless you tell us this was the *whole* interaction.

    What if X spoke personally with someone from DEF and showed the message?

    Or even by phone, and the DEF person receives emails from ABC Team, e.g. ABC Team's mailing list also broadcasts to DEF Team, or that person is actually in both mailing lists.

  25. 640k says:

    If there's a problem with a car, you don't email a assembly line worker. That's wrong in so many ways.

    As said, there's not very much information supplied by Raymond (it wouldn't have hurt to specify more to keep people from guessing), about SLAs or if X, ABC and DEF are isolated legal entities or if all work at the same company.

    But anyway, if a ABC team member should send an email, or open a support case, to DEF then the ABC team member would be the "customer". Many companies have policies which disallow this practice, the support case should be mailed in by the real customer, else the ABC member can get in trouble for wasting his own time and DEF's time. You do NOT cc DEF, only reply how the real customer should do it.

Comments are closed.

Skip to main content