September, 2007

  • The Old New Thing

    I mean, come on, these are laptops


    Last year, Weekend America (co-hosted by former Seattleite Bill Radke—we miss you, Bill!) did a story on the Princeton Laptop Orchestra, which calls itself PLOrk. It's an interesting experiment, but computer music doesn't really move me. It's not the computer-ness that bugs me (I was fascinated by music played on Gameboys, after all) but rather the lack of traditional musicality.

    That said, the chord that opens the piece on online gambling creeps me out. Not because of the piece itself, but because it is dangerously reminiscent of the chord played at the Tulalip Casino, a steady synthesized triad played at low volume so you can barely hear it. And after a while, you simply stop hearing it, and then you have to whack yourself on the head and make yourself hear it again because allowing it to sink into your subconscious means that they've won.

  • The Old New Thing

    Whenever there is a coordination problem, somebody says, "Hey, let's create a process!"


    Whenever there is a coordination problem, somebody says, "Hey, let's create a process." Now you have two coordination problems.

    I see this over and over, and paradoxically the people who create a process for managing a coordinating problem come off looking like proactive problem-solvers who get ahead of the problem. They're the go-getters, the people who look at each problem as an opportunity for continuous improvement. All that great management buzzword stuff.

    It doesn't matter whether or not the process actually works, because failure is an orphan, and besides, nobody follows up a year later to see whether your process actually improved things or whether it was abandoned six weeks after roll-out. You get the credit for proposing the process in the first place.

    Consider this problem at a hypothetical toy company: Some rumors have started that one of their toy cars is dangerous because of a wiring flaw that can result in excessive heat and possible fire. (It doesn't matter what the crisis is. I just made up something vaguely plausible.) Employees all over the company are getting email from their relatives asking about the toys, but the employees don't know what the story is either. Presumably, the safety department is investigating the problem and providing guidance to the PR and marketing departments so they can prepare a public response, and if there really is a problem, they're working with the product recall team to organize how the recall will be carried out, and they're working with the product engineering team to figure out what changes need to be made to the product to avoid the problem. In other words, the safety department is up to their ears in crisis.

    A employee from the dolls department, whose brother asked him about this toy car problem, can't find any information on the status of this issue and sends email to the "Employee Issues" alias, and a dozen people chime in with "Yes, please, we would like this information, I want to know what I can tell my brother and everybody else who is asking me about it. I might even post it on my blog so I can try to counteract some of the out-of-control rumors that are out there."

    A half hour later, somebody from the safety department responds, "Yes, we know about this, we're working on it. Please don't say anything publicly since we're still investigating."

    Somebody watching the saga unfold proposes a process by which employees can be kept up to date on the status of these types of emergent crises.

    • Create an internal web site that contains a list of all current emergencies at the company, their status, what information is speculation and what information is solid, which pieces of that information can be revealed to the public, and recommended phrasing for the information when it is revealed.
    • Whenever there is an emergency, the people responsible for responding to the emergency update the web site with the status of the investigation and the other information listed above.

    This is the wrong solution to the problem.

    The reason why this is the wrong solution is that it suffers from the classic "Create work for somebody else" problem. The people who benefit from this site are not the same people who would make the site useful. This doesn't give the people who make the site useful much incentive to do so. They're busy dealing with the emergency. They don't want to waste the time of one of their valuable investigators to do "internal PR".

    This scenario repeats itself on a less dramatic scale with various types of inter-group coordination problems. One group wants to be kept advised of the progress of another group for whatever reason. But if the second group doesn't need the first group for anything, they have no incentive to keep the first group informed.

    For example, suppose the first team provides an interface that the second team uses, and the first team decides that they need to redesign the interface for whatever reason. During the transition, the first team provides both interfaces so that the second team can transition from the old to the new, with the request that the second team let them know when they have finished transitioning to the new interface so they can remove support for the old one.

    Unless the first team keeps on top of things, the second team will probably forget to tell the first team when they have completed the transition, or they may even forget to transition to the new interface at all! After all, the old interface still works.

    In this case, the traditional way of making the second team care is to file a bug against them saying, "Stop using the old interface." That way, it shows up in their bug statistics as a reminder, and when they actually do the work, they can resolve the bug back to the first team. But you can imagine a scenario where the information the first team wants is more of a continuous nature rather than a single event. (Since bugs track single events.)

  • The Old New Thing

    Volunteers help save fruit from home fruit trees from going to waste


    It's the season where people with fruit trees in their yard are drowning in fresh fruit, be they pears, apples, plums, whatever. It's not long before you find yourself desperately looking for people to give it away to, having pretty much run out of things you can make plums into.

    This is where Community Fruit Tree Harvest steps in. (Coverage in The Seattle Times and The Seattle Post-Intelligencer. There's also Lettuce Link for donating produce from your home garden.)

    The volunteers at Community Fruit Tree Harvest will visit your house and pick the fruit from your tree, donating it to local food banks. Everybody wins: You don't have to deal with all the extra fruit, the food banks get fresh fruit, nothing goes to waste. (This is one of those "Why didn't somebody think of this sooner?" type of programs.) Contact telephone numbers are on the web pages. It appears that they currently cover the Wallingford, Phinney Ridge, and Green Lake neighborhoods.

  • The Old New Thing

    Does creating a thread from DllMain deadlock or doesn't it?


    Let me get this out of the way up front: Creating a thread from DllMain is not recommended. The discussion here has to do with explaining the behavior you may observe if you violate this advice.

    Commenter Pete points out that "according to Usenet" creating a thread in DllMain is supposed to deadlock, but that's not what he saw. All he saw was that the thread entry procedure was not called.

    I'm going to set aside what "according to Usenet" means.

    Recall how a thread starts up. When you call CreateThread, a kernel thread object is created and scheduled. Once the thread gets a chance to run, the kernel calls all the DllMain functions with the DLL_THREAD_ATTACH code. Once that's done, the thread's entry point is called.

    The issue with deadlocks is that all DllMain functions are serialized. At most one DllMain can be running at a time. Suppose a DllMain function is running and it creates a thread. As we noted above, a kernel thread object is created and scheduled, and the first thing the thread does is notify all the DLLs with DLL_THREAD_ATTACH. Since DllMain functions are serialized, the attempt to send out the DLL_THREAD_ATTACH notifications must wait until the current DllMain function returns.

    That's why you observe that the new thread's entry point doesn't get called until after you return from DllMain. The new thread hasn't even made it that far; it's still working on the DLL_THREAD_ATTACH notifications. On the other hand, there is no actual deadlock here. The new thread will get itself off the ground once everybody else has finished doing their DllMain work.

    So what is this deadlock that Usenet talks about? If you've been following along, you should spot it easily enough.

    If your DllMain function creates a thread and then waits for the thread to do something (e.g., waits for the thread to signal an event that says that it has finished initializing, then you've created a deadlock. The DLL_PROCESS_ATTACH notification handler inside DllMain is waiting for the new thread to run, but the new thread can't run until the DllMain function returns so that it can send a new DLL_THREAD_ATTACH notification.

    This deadlock is much more commonly seen in DLL_PROCESS_DETACH, where a DLL wants to shut down its worker threads and wait for them to clean up before it unloads itself. You can't wait for a thread inside DLL_PROCESS_DETACH because that thread needs to send out the DLL_THREAD_DETACH notifications before it exits, which it can't do until your DLL_PROCESS_DETACH handler returns.

    (It is for this thread cleanup case that the function FreeLibraryAndExitThread was created.)

  • The Old New Thing

    Belated follow-up: Mike Goodspaceguy Nelson running for public office, again


    Undeterred by his failure to win a Senate seat last year, Mike Goodspaceguy Nelson once again ran for King County Council. I can't bring myself to listen to his appearance on the local public radio station (fortunately, he wasn't running in my district). You can read his and opponent Dow Constantine's candidate statements on the King County Elections Web site.

    I stumbled across a candidate questionnaire that the Historic Seattle Preservation Foundation submitted to all of the candidates for King County City Council, and comparing Michael Goodspaceguy Nelson's response with the response from mainstream candidates Dow Constantine and Jane Hague, I have to say that Nelson comes off looking pretty good. He answers each question honestly, assigning medium or even low priority to the historic society's hot-button issues, describing how they fit into his overall plan. By comparison, Constantine and Hague pander to the foundation by rating everything as high priority. The sole "medium priority" was their assessment of how the council as a whole prioritized an issue. "See? I pander to you better than the rest of the council!"

    (Note: This message was pre-recorded. The race was no contest; Constantine won easily.)

    In other local election news, the race for another seat on the King County council has been suffering a series of bizarre twists. The incumbent Jane Hague was arrested for drunk driving back in June, and the news was kept quiet until just days before the election, at which point local politics were thrown into a tizzy.

    But wait, there's more. You'd think the opposition party would be ecstatic, but they were too busy dealing with their own problems to care, for the opposition candidate was perennial also-ran Richard Pope. ("Some people go to baseball games or go fishing. Richard files for office.")

    How did a fringe candidate become the opposition candidate? State law permits candidates to claim whatever party affiliation they wish, without needing permission from the party itself, and Pope has taken advantage of this, changing parties three times during his career. (I'm simplifying; read the story for details.)

    So now we have a choice in November between an accused drunk and a fringe candidate. It's going to be a weird election.

  • The Old New Thing

    Knock knock. Who's there? Not you any more.


    One of my many favorite Dilbert cartoons is also one of the earlier ones. It's the first strip reprinted in this article.

    It may not actually have happened, but I was told that that one project many years ago replaced its lead manager. While noteworthy, this sort of thing happens often enough that people take it in stride. What put it into a higher category, however, was that the email that announced this change at the top was sent while the outgoing manager was out of the country on vacation.

    One can imagine the now-former manager's surprise upon returning to the office.

    "Dum di dum, catching up on email, hey what the..."

    Now, the outgoing manager may very well have known about this change before heading out on vacation, but the story is funnier (and I therefore like to believe) that it was a surprise.

Page 4 of 4 (36 items) 1234