Before designing and implementing around an assumption, it helps to check that your assumption is true

When your component depends on another component in the project, and that other component is missing features you need, you have a few ways of resolving the situation. Most people would recommend working with the people responsible for the other component during the project planning phase and coming to some sort of understanding about what you require from them and when they might be able to provide it, if at all.

And then there's this approach. This imaginary email conversation takes place about halfway through a project:

From: David Doe

Hello, widget team. I'm David Doe, from the doodad team.

Do widgets support cross-domain deserialization? If not, are there any plans to support it?

A reply quickly arrives from the head of the widget team, answering both of the questions.

From: Wendy Wilson

No, widgets do not currently support that feature, and there are no plans to add it.

The doodad team becomes a bit more concerned.

From: David Doe

This is really important to us. Doodads need to be able to deserialize widgets across domains, and we need to know when that support will be implemented.

Like the sign says, Lack of planning on your part does not constitute an emergency on my part.

Comments (24)
  1. Mark (The other Mark) says:

    From: Wendy Wilson

    There is no public interface for deserializing widgets across domains.

    From: David Doe

    But we need to be able to deserialize cross domain widgets for the confabulator. It’s very important

    From: Wendy Wilson

    What I tell you three times is true…. No, I’m just joking with you, if you keep asking the question, eventually the answer changes.

  2. dave says:

    "…and we need to know when that support will be implemented."

    I thought the correct answer to that one was "When you implement it"?

  3. Not forgetting the reply if widgets are an open source project:

    "If you need cross-domain widget deserialisation, feel free to download the existing 7,500,000-line codebase that took twenty-five-person-years to hack into a stable form and add support for it yourself."

  4. Gabe says:

    Sometimes the assumptions are not recognized beforehand because they are not obvious. If it is the default that deserialization works cross-domain, it might not occur to anybody that widgets wouldn’t do it until they actually try. In fact many people may not realize that it was even possible that deserialization might not work cross-domain.

    A more real life example is that you might assume that if you can write value V to address A, then reading back address A will return value V. This is such a basic assumption that no ordinary programmer would consider that it might not be true. How could it ever be false? When address A is a memory-mapped device register, there’s no telling what will come back when you read it. Of course no normal programmer considers such things.

  5. Michael says:

    I’ll bet I’d get a wonderful sense of schadenfreude if I knew how this exchange ended.

  6. D. Roberts says:

    "Like the sign says, Lack of planning on your part does not constitute an emergency on my part"

    Yeah, screw the product and the end user who may need XYZ functionality that the doodad team is trying to implement: Just isolate your team, treat outside teams as outsiders, and stick your fingers up at them if the (inevitable) slippage or unexpected requirement pops up. You’ve planned ahead, they haven’t – the "I’m alright Jack" approach. The end product is irrelevant as long as our piece is done…

    Seriously, if this represents the kind of development that happens inside of MS, it says a lot about why so many things are hopelessly broken in your products.

  7. dave says:

    re: D. Roberts

    There’s a difference between

    (1) "OMG! We totally forgot to check for cross-domain deserialization support, and now we have a problem. Can you help us?"


    (2) "We couldn’t even be bothered to talk to you before, and now we expect you to drop everything and solve our problem for us. When will you have it done by?".

    Note that Mr. Doe is not even asking "can you do this?", he is demanding to know "when will you have this done?".

  8. Bob says:


    There may be a difference to you as to how the request is phrased.  I think that {D. Roberts}’s point is that it does not matter to the level of management which includes both teams, and certainly does not matter to your customers.

    I work in a different technical area (microprocessor design) but the issues are similar. We may grumble privately, but would immediately get together with the other team and understand each others technical issues & work out a solution that works for all.

    [Obviously, the next step is to have a meeting between the widget and doodad teams to work out what can be done given the resources available. That wasn’t the point of the story. The point was that the doodad team relied on a nonexistent feature and was presumptuous to assume that the widget team had already agreed to do the necessary work and demanded an ETA. -Raymond]
  9. DrkMatter says:

    @D. Roberts

    "Yeah, screw the product and the end user who may need XYZ functionality that the doodad team is trying to implement"

    I did not read that sign as saying that you should give the finger to the other team, simply that it is primarily their responsibility to clean up their own mess. In my limited experiences, teams that come up with this kind of demand, especially worded in such a manner, never tried to look at alternatives from their own side. They simply see their part of the projects as The Most Important Part, and try to bully other teams into accomodating them, rather than attempting to use a more concerted approach.

  10. Carmen says:

    What I’ve learned from this is that when Raymond doesn’t make the pre-emptive "obvious  snarky comment", one of his commentors will certainly do so.  This is one of the first in awhile to not include it, but D. Roberts made sure we did not miss out in the snark by equating the story to how MS does all of their product development.

    That’ll teach you to change your pattern, Raymond!

  11. DonBoy says:

    OK, <i>my</i> snarky comment is to remark on this common and yet annoying use of the word "need":

    <i>Doodads need to be able to deserialize widgets across domains</i>

    No. <i>Doodads</i> don’t need anything, because objects (in the general sense, not the OOP sense) do not have needs.  <i>You need</i> doodads to…etc.  This is not as trivial as it sounds, because the other way makes it sound like an established fact about doodads, instead of a need on your part.

    And then we can get to what it means for you to need it, but that’s another matter.

  12. Alexandre Grigoriev says:


    My favorite at my previous place was when the ASIC designers removed hardware timer registers from the chip design. Imagine the driver team surprise when pulse dialing didn’t work anymore. And ring frequency detection, too.

  13. Alan Braggins says:

    Yeah, screw the product and the end user who may need XYZ functionality

    Because obviously no end users will actually need the work the widget team have already planned more than they need doodads….

    How many times has Raymond explained that whenever you say "there should be feature X", you have to say what you would be prepared to drop to get the resources for X?

    ASIC designers removed hardware timer registers

    There’s a huge difference between failing to add new features the instant you are asked for them, and dropping existing features without warning people.

  14. Spike says:

    @Nick Fitzsimmons

    "Not forgetting the reply if widgets are an open source project:

    "If you need cross-domain widget deserialisation, feel free to download the existing 7,500,000-line codebase that took twenty-five-person-years to hack into a stable form and add support for it yourself."


    With 200 working days in a year that equates to 1,500 lines of code produced per person-day.  I’m finally starting to understand the success of Open Source software!

    BTW Can we say man-year or person-year?  Are there really any women working on Open Source projects?

  15. alexk says:


    Here’s the whammy:

    Are there really any "men" working on Open Source either?

  16. @D. Roberts, you’re way off. An incompetent subteam that is able to flourish and appear wildly successful despite its own incompetence, by putting pressure on competent teams to make up the shortfall due to its own errors, will ultimately be the ruin of the whole enterprise. Microsoft (or any company) and its customers would, in the long run, benefit from holding such incompetence to account before it can do too much damage.

    This is something that happens naturally in the marketplace, but it can usually only be simulated within a large bureaucracy, and that is only possible if all competent teams "police" the system by staying focused, and attempting to act at all times as if they are spending their own money on their own goals.

  17. Mark (The other Mark) says:

    When will I remember that humor has no place here?

    Pre-emptive snarky comment- "Isn’t humor usually funny?"

    Just to be clear, I was making fun of "David Doe" for asking essentially the same question repeatedly, after having already received the answer. I was attempting to do so by referencing another post here.

    Of course, in real life, there would be more to it. Perhaps David could explain what they are trying to accomplish, and Wendy could explain how to accomplish that goal with the current Widget framework?

    Or, if Doodads really do need this feature, then resources can be reallocated as needed. If adding this to widgets would take too much resources, then maybe they can cut the doodad feature entirely, and use those people to implement frumious support on the Bandersnatch instead?

  18. Jason Haley says:

    Interesting Finds: May 28, 2009

  19. abadidea says:

    Spike: Of course there are women working on open source (and commercial) projects… I’m working on one myself in fact 8)

    (Pre-emptive "yes you were probably joking" acknowledgment)

  20. JamesNT says:

    I have conversations like that with colleagues and clients all the time.  One of my personal favorits:


    We have found a bug in XYZ program that we bought from so-and-so vendor.


    What is XYZ?  I didn’t realize you had purchased this software.


    We bought it 2 weeks ago.  When can you come in and fix this bug?


    I’d be happy to take a look at the bug and help you submit a fix request to whatever tech-support this software has.


    We didn’t purchase a support option with this software because it was another $500 a year.  Why can’t you fix it?  Aren’t you a programmer?


    I am a programmer but I don’t have access to their source code.


    This problem is not acceptible to our productivity needs.  Please send us an update tomorrow on what you can do to fix or workaround this problem.

    And that last one came at 4pm.


  21. Aaron G says:

    @JamesNT: Wow, I’ve seen dumb requests but that one really takes the cake.  I think the only reasonable response to that is to walk into his office with a rolled-up magazine and whack him repeatedly on the side of the head with it while saying "No!  BAD client!" in a stern voice.

    OT: I want that sign for my office.  I’m in a corporate environment, and one of the most common types of request is where a known operational issue went unnoticed or just unresolved for several months, somebody finally decided to raise hell, and I need to provide a "quick fix" because they can’t make their deadline using normal means.

    I always have to explain that even if I were capable of providing such a quick fix, which I often am not, I happen to report to a different department with different priorities and that I’m not about to miss three of my own deadlines just so they can meet theirs.  If it’s so urgent, they can bring it to management with a cost analysis and formally request engineering resources to help them clean up their mess.

  22. Nicole DesRosiers says:

    Yeah, I’ve totally been there.  Frequently.  My best example of this was when I got to watch executive ping pong in four-hour meetings for the next week.

    I get it, software development is hard.  Requirements gathering is hard.  Elucidating one’s requirements is hard.  But if you forgot a non-obvious requirement when you were asking me to design a feature for you, could you have the grace to accept the fault for that (or not place blame at all) instead of coming down on me like I’m a complete moron and if it weren’t for me, the product would be smooth sailing towards the horizon?

  23. Cheong says:

    More often, in the case I’ll just go on and search for alternative component if they have no plan to add it.

    You ought to try things out before you buy a component. There’s some reasons why trial / evaluation version of components exists.

Comments are closed.

Skip to main content