November, 2008

  • The Old New Thing

    If everything is top priority, then nothing is top priority


    Last time, I mentioned that eventually everything is top priority. A similar topic is what I'm calling priority inflation, which takes more than one form.

    Today's priority inflation is the introduction of new "top priority" items. (Chris Becker has some thoughts on this topic as well.)

    "XYZ is very important to our project. Please make it your top priority." A few weeks later, "ABC is very important to our project. It should take priority over all other issues." When this happens, I like to ask, "Is this even more important than XYZ?" I've done it so much that my management has changed the way it introduces new top priorities: Instead of just saying "Please make ABC your top priority," they list out all the existing top priorities... in priority order.

    ABC is very important to our project. There are just a handful of ABC issues remaining, and we would like to close them out by the end of the month. If you have an ABC issue, please make it your top priority. To summarize:

    1. ABC issues.
    2. XYZ issues.
    3. DEF issues.

    I like this approach because it forces management to understand and acknowledge where their priorities are. If you're going to ship a product, you have to make hard choices, and one of them is deciding where your priorities are.

    If everything is top priority, then nothing is top priority.

    Update: Sometimes, the answer to "Is this even more important than XYZ?" was "No, XYZ is still more important than ABC." So it's not a gimme that if somebody says that ABC is top priority, it replaces what used to be the top priority. That's why it's important to keep track.

  • The Old New Thing

    Adventures in product testing: This phone's so hot, it'll set your head on fire


    Actually, this is pretty cool. A phone that sets your head on fire. Most people charge extra for that.


    Go ahead, make up your own joke.

  • The Old New Thing

    If you wait long enough, everything is our top priority


    I always crack a smile whenever I hear or read someone say that "XYZ is our top priority." The person may believe it at the moment they say it, but just wait a little while, and soon there will be a new top priority.

    If you call the person out on their shifting priorities, they usually come up with some hand-waving explanation that the two "top" priorities are actually the same thing.

    Last week, you said that customer satisfaction was our top priority, but just now you said that our employees' well-being is our top priority. Which one is the real top priority? In other words, which is more important, customer satisfaction or employee well-being?

    "Well, you see, if our employees are happy and healthy, that shows itself in the quality of service we provide our customers, so the two are really facets of the same underlying issue. Which is our top priority."

    But there can be a conflict between the two. For example, longer hours of operation improve customer service, but it also takes a toll on the workforce. Which goal is more important?

    "That's an interesting question. Obviously we would work very hard to try to avoid such a conflict. I'm confident that my leadership team will be able to address both issues without having to sacrifice on either one."

    Wait, now they are separate issues again? You said earlier that they were the same issue.

    "I think I've answered your question. Anybody else have a question?"

  • The Old New Thing

    Is second-hand advice better than no advice at all?


    Commenter Grow Up (if you're so grown up yourself, why not use your real name?) took issue with the second-hand advice I gave when the discussion of protecting sensitive data. In that discussion, I gave second-hand advice on how one could protect information, and one reader apparently thought I was trying to malign said second-hand advice or was holding it up as non-authoritative. (In case you forgot: Everything here is non-authoritative. It's all just my interpretation of the world around us. And that interpretation is often wrong. Don't make me bring back the nitpicker's corner.)

    I added the second-hand advice only because upon re-reading, I noticed that I wrote a lot about what you shouldn't do but didn't write about what you should do. I didn't want to put my own neck on the line in an area I am not an expert, so I passed along second-hand advice instead, figuring second-hand advice was better than no advice at all.

    It may surprise you that I am in fact an expert at very few things. I do have a rather extensive background in general programming principles, and I use that experience to "fill in the gaps" in places others may need help doing so. For example, I'm pretty good at the "Imagine what the world would be like if that were true" game because I've seen a good amount of the computer world and can think of scenarios that others may miss. On the other hand, I'm good at the "What if two people did this?" game only because I bother to play it at all. (Usually, the answer to the question "What if two people did this?" is obvious. People merely forget to ask it.) I'm also good at reverse-engineering history. I can see how something evolved and work out why it ended up that way.

    So, suppose there's a topic that I know a little bit about but not enough to come up with an expert recommendation. For example, I may want to caution you against doing something but I don't have a good answer as to what you should be doing instead. Here are my options:

    1. Become an expert in the topic and develop a personal recommendation. If it's worth doing, it's worth doing well.
    2. Pass along somebody else's recommendation. Second-hand advice is better than none.
    3. Develop an uninformed recommendation. Even though it's bad advice, at least it's my bad advice.
    4. Don't provide any recommendation at all. If you can't stand by it, then don't write it.
    5. Don't write the article in the first place. If you can't do a complete job, then don't do it.

    The first option is not going to happen; I don't want to become an expert in the topic. The last one is also unpleasant, because I do want to warn against what I consider to be a bad practice, or at least I may have some thoughts that I think are worth sharing. The middle option isn't very pleasing either. Besides, this is a blog, not a textbook. If you want a thorough treatment of a topic, you're looking in the wrong place. There are plenty of other bloggers who throw out half-baked ideas. I should be able to do it, too.

    Like I just did.

  • The Old New Thing

    You'd think this sort of disclaimer on children's modeling clay would not be necessary


    "Molded results vary depending on child's age and level of skill."

  • The Old New Thing

    Why bother with RegisterWaitForSingleObject when you have MsgWaitForMultipleObjects?


    Commenter kokorozashi wonders why you should bother with RegisterWaitForSingleObject when you have MsgWaitForMultipleObjects already. If you want to pump messages and wait for a kernel object, then you can change all calls to PeekMessage, GetMessage, and WaitMessage to replacement functions that use MsgWaitForMultipleObjects. Isn't that enough? Why waste an entire thread just to wait for that object?

    If you're so clever that you can modify every call to PeekMessage, GetMessage, and WaitMessage, then more power to you. But in order to do this, you'll have to restrict the functions you call, because all sorts of functions contain their own message loops. Do you call MessageBox? Or DialogBox? Those functions contain a modal loop. (After all, they don't return until the user dismisses the dialog box; somebody has to be pumping messages because you're not.) Indeed, you can't even call DefWindowProc since that function goes into a modal loop if the user, say, grabs the caption bar and drags the window around: That drag loop happens inside DefWindowProc.

    If your thread has any sort of visible UI, this sort of extreme control of all message loops is unreasonable. You have no practical choice but to have the wait happen on some other thread and either respond to the signalled object on that thread or post a notification back to the UI thread to do the work.

    The advantage of RegisterWaitForSingleObject over creating your own thread for waiting is that the thread pool functions will combine multiple registered waits together on a single thread (by the power of WaitForMultipleObjects), so instead of costing a whole thread, it costs something closer to (but not exactly) 1/64 of a thread.

  • The Old New Thing

    Email tip: If you ask a question that can be answered in only one way, but that's not the answer, don't be surprised that nobody responds at all


    It's not infrequent that I see somebody ask a question that can be answered in only one way. But if that's not the answer, then nobody will respond.

    Is there a module that does XYZ?

    This question can be answered in only one way: "Yes, here it is." If nobody has written such a module, nobody is going to reply saying, "No, nobody has written the module you request," because that would require the responder to prove a negative.

    "I have scoured the entire planet, including code sitting on a hard drive in somebody's mother's basement, and have verified that there is no module that does XYZ. Furthermore, I have altered the rules of the universe to ensure that nobody will write such a module in the time between I completed this investigation and the time you receive this message."

    If you ask a question asking whether something exists, there's only one possible response, because nobody is going to say that the code you request has never been written.

    So far, nothing is wrong. Perhaps the person who asked the question was about to write an XYZ module, but wanted to make sure the effort was not being duplicated.

    However, there are some people who fail to realize that they just asked for proof of a negative, and send a follow-up:

    Resending. Can somebody please tell me whether this module exists?

    What's particularly scary are the people who ask the question in such a way that they are not only asking for proof of a negative, but in fact proof of a perpetual negative. There was one customer who was rather insistent upon receiving an answer to a question of the form "Will there ever be a tool that will...?"

    And once again, the round-up of unhelpful or rude subject lines I've seen in the past five months:

    • Please help
    • Some help please?
    • some help please? [lowercase this time]
    • KB980665 - customer issue!
    • I need urgent help
    • Windows Vista SP1
    • SP1?
    • Need help -- SRS299792458
    • a problem
    • Possible Bug [capital letters make it sound Important]
    • Hi
  • The Old New Thing

    Rearranging the cities into a much more visually pleasing arrangement


    My friend the seventh grade teacher gave an assignment wherein students were to produce a map of the state of Washington with various required elements, among them, a selection of major cities in the state. Some students failed to understand that the purpose of a map is to represent where the cities are and not to dictate to the cities where they should be, for they moved the cities around in strange ways.

    • Some students put Port Angeles 100 miles inland nowhere near any body of water. Psst, it's a port. Ports are not as effective when they are 100 miles inland.
    • Other students took the idea of a port too far and put Port Angeles 100 miles out to sea. This sort of misses out the other half of being a port, which is being connected to land.
    • But the winners of the Unclear on the concept award are the students who moved the cities around. "All these dots looked all crooked and stuff, so I moved them around to make a straight line. Was that wrong?"

    Moving the dots around to make a more visually pleasing arrangement might work if you were designing, say, a transit map, where the topology of the connections is the important thing rather than their physical arrangement in space. But this wasn't one of those times.

    Bonus chatter: Another student decided to embellish the map by coloring everything outside the boundaries of the state in blue. Psst, the color blue has special meaning in maps. Washington is not an island.

  • The Old New Thing

    Why is the maximum boot.ini delay 11 million seconds?


    I mentioned in passing that the maximum delay you can specify in boot.ini is about 11 million seconds. I'm disappointed but sadly not surprised that everybody focused on that number and completely missed the point of the article.

    First of all, the value of 11 million was not a conscious limitation. It's just an artifact of other limitations. The delay is specified in seconds in boot.ini, but internally it is converted to BIOS clock ticks. (Remember, this is a boot loader; there's not much infrastructure available yet.) The conversion is done in 32-bit arithmetic, and 4 billion BIOS clock ticks at 18.2 ticks per second is about 110 million seconds.

    Wait, but you said 11 million seconds, not 110 million seconds.

    Well, yes, but the conversion is done in 32-bit integer arithmetic: BiosTicks = BootIniSeconds * 182 / 10. A value for BootIniSeconds larger than about 11 million will result in a signed integer overflow in the intermediate product.

    That's why the limit is 11 million seconds. It's a storage limitation, not an arbitrary cutoff. And it is indeed the limit of a natural data type, just hidden behind some other computations. (SB figured this out, though I fear that this shout-out will only serve to encourage people to speculate even more wildly than they already do in the hopes of earning a future shout-out.)

    Now you'd think this would be plenty enough of a boot delay. I mean, it's already much longer than the maximum amount you can delay with a single call to Sleep or WaitForSingleObject. And who would ever need a computer to pause four months before booting? Yet there's one commenter who thought 11 million seconds wasn't enough: "What if I want a timeout of 129 days?" If you need a timeout of 129 days, then go buy a custom hardware timer device that waits 129 days after the onset of power before allowing current to flow. This same commenter has difficulty comprehending that just because you're capable of delaying something for a specific length of time and you're capable of never doing it at all, that doesn't mean that you are also capable of delaying something for an arbitrary length of time.

    One commenter suggested that the problem could be solved by using a bignum library. Before you solve a problem, you first have to be sure that what you have really is a problem in the first place. I have yet to hear of any customers who are running into the 11 million second limit. Using bignums here would be a solution in search of a problem. "Hey, let's consume valuable developer and tester resources in order to add a bunch of code to a tightly-constrained environment to cover a case that nobody cares about." (And I failed to live up to my promise to Ulric merely to incorporate this lecture by reference in the future.)

  • The Old New Thing

    Doesn't matter what your marketing technique is for your compiler if nobody actually writes code in your language any more


    I mentioned Terry Zink's Anti-spam blog ("Protecting your mail from the scum of the internet") during one of my quarterly "borg-edition" linkfests. The article about how much money a spammer actually makes was quite interesting. One thing that caught my eye was the insanely low sales rate that was needed in order to make the enterprise lucrative. Only 0.12% of the messages get clicked on, and of those, only 0.5% result in a sale, yet with a sales rate of just 0.0006%, the spammer pulled down an impressive $7690 per week, or over $300,000 per year. (Researchers who infiltrated the Storm botnet have their own estimates. Terry's story is more interesting to me since it comes from an actual (reformed) spammer.)

    That reminded me of a story told to me by the person who worked on Microsoft's FORTRAN compiler. (Yes, we had one.) He mentioned that one of their attempts to market the compiler was to include a Microsoft FORTRAN business reply card in a targeted mailing to subscribers to a well-known technical computer magazine.

    "Normally, these sort of targetted direct mail efforts generate maybe a 3% or 4% response rate if you do well. We got two."

    — Two percent. Well, that's not too bad, considering this is FORTRAN we're talking about.

    "No, I didn't say two percent. Just two. As in, we received two postcards."

    — Oh.

Page 2 of 4 (33 items) 1234