The 2GB Windows XP Hibernation Problem

If you ..

• use Windows XP SP2 of any flavor
• have 1+ gigabytes or more of system memory
• use hibernate functionality

.. you may have experienced this error at some point when attempting to hibernate:

I know I have. It drives me nuts, because my system fails to hibernate after I've already initiated the hibernation process and walked away from it. This is on my desktop*. You can imagine how catastrophic this could be on a laptop; you'd be putting a laptop in your bag that was still fully on!

To avoid the error, install this Microsoft hotfix, which is graciously hosted by Owen Cutajar. It's from Microsoft KB909095, which also explains the problem in a bit more detail:

To prepare the computer to hibernate, the Windows kernel power manager requires a block of contiguous memory. The size of this contiguous memory is proportional to the number of physical memory regions that the computer is using. A computer that uses lots of RAM is likely to use more physical memory regions when the computer prepares to hibernate. Therefore, a larger amount of contiguous memory is required to prepare the computer to hibernate.

Additionally, the number of physical memory regions varies according to the programs, services, and device drivers that the computer uses. Therefore, the hibernate feature occasionally fails.

When the Windows kernel power manager detects that the hibernate feature has failed, the hibernate feature remains disabled until you restart the computer.

I originally researched this back in December, but the problem wasn't happening with enough frequency to make me call Microsoft support and dig up a hotfix. Now it is. And people have mirrored the patch so we don't have to go through the busywork exercise of calling Microsoft support to obtain a necessary hotfix. What a ridiculous policy.

* I would use sleep, but the motherboard I use isn't smart enough to restore the correct overclocked CPU speed. I get bumped down to stock CPU speeds every time I resume from a sleep state.

STOP! Having Trouble?

From Engadget's review of the iRiver H10:

So the first thing we noticed about this player when we opened it up was, unfortunately, a huge orange flyer [..]

From Larry Osterman's review of the iRiver H10:

My concerns started when I opened the box. To the left of the H10 was a plastic bag with the manual etc. On the top of the plastic bag, plain to see was a bright orange piece of paper with:

Do you really want your user's out of box experience to be a bright orange warning sign that screams STOP! and Having Trouble? That negative first impression sets the tone for the rest of the device's life. It's all downhill from there.

It's details like this that drove Omar back to the iPod. But that's a natural consequence, as Omar points out, of the business model: Apple owns the device, the software, and the music licensing. They control the entire experience. Nobody can screw that up behind Apple's back.

Now compare that with the out of box experience of the new Lenovo T60 Thinkpad we received at work today. This is the taskbar after the machine has literally been booted for the first time:

The operating system is loaded down with so many pre-installed craplets that the taskbar takes up half the screen. The hardware is excellent, but you'd never know that based on the abysmal software experience you're about to have. And that's just the taskbar! Take a look at the full desktop screenshot. It's even worse.

Is it any wonder that I recommend people wipe their systems as soon as they receive them and perform a clean install of Windows XP SP2? If I've learned anything about computers in the last 35 years, it's this: if you leave the user experience up to third parties, they will screw it up behind your back. Royally. Every single time.

That's why I'm encouraged by the Windows Media Center team's insistence that they tightly control the core user experience. As Charlie Owen explained to me at MIX06, third parties can create all the external add-ins they want, but they can't mimic the Media Center UI, and they definitely can't muck around with the core functionality of Media Center.

Good call.

I Shall Call It.. SomethingManager

Alan Green rails against the meaninglessness of SomethingManager:

How many classes do you come across named 'SomethingManager'? Any decent sized commercial system seems to have plenty - SessionManager, ConnectionManager, PolicyManager, QueueManager, UrlManager, ConfigurationManager, or even, sadly, EJBManager.

A quick look at the dictionary entry for "manager" and "manage" gives at least ten different meanings - from "to make and keep compliant" through to "to achieve one's purpose". I remember one day when the receptionist briefly retitled herself as Switchboard Manager. The common semantic to all these definitions seem to be a vague "looks after stuff".

This imprecision makes Manager a bad word to use in naming classes. For instance, take a class named "UrlManager" - you cannot tell whether it pool URLs, manipulates URLs or audits the use of them. All the name tells you is that this class does something with URLs. On the other hand, the name "UrlBuilder" provides a much clearer picture of what the class does.

In the Java world, the Manager suffix is thrown around a lot. Almost anywhere you have a class that is responsible in any way for other objects, it automatically earns the Manager label.

There's nothing more ambiguous than a SomethingManager. Avoid this word. Alan proposes a few alternatives in his blog post that might be helpful in narrowing down what your class actually does.

Giving your classes and objects good, descriptive names isn't easy. Steve McConnell provides a few helpful guidelines for routine naming in Code Complete:

1. Describe everything the routine does
   And we mean literally everything. If that makes the name ridiculously long, the name isn't the problem. Your routine is.

2. Avoid meaningless, vague, or wishy-washy verbs
   Like UrlManager, or HandleOutput(), or PerformServices(). Be specific. What does it do? If you can't answer that question succinctly, it may be time to refactor the code until you can.

3. Don't differentiate routine names solely by number
   I include this only for completeness. If you ever find yourself writing OutputUser1() and OutputUser2(), God help you. And God help the team you work with.

4. Make names as long as necessary
   According to McConnell, the optimum name length for a variable is 9 to 15 characters; routines tend to be more complex and therefore deserve longer names. Make your names as long as they need to be in order to make them understandable.

5. For functions, try using a description of the return value
   An easy, straightforward rule. Some examples are printer.IsReady(), pen.CurrentColor(), etcetera.

6. Use opposites precisely
   For every Open(), there should be a Close(); for every Insert(), a Delete(); for every Start(), a Stop().

7. Establish conventions for common operations
   This is best illustrated with an example, and McConnell provides an excellent one:

   employee.id.Get()
   dependent.GetId()
   supervisor()
   candidate.id()
   

   Now how do I get an Id again?

I'd say renaming classes and variables is one of my most frequent refactoring activities. Creating good names is hard, but it should be hard. It's difficult to tell what something should be named until you're completely finished writing it. And like most code, it's never quite done, so the name may change over time. Succinct, descriptive variable, object, and function names can make the difference between Daily WTF code and.. well, code you'd actually want to work on.

How Not To Become a Rockstar Programmer

Tom's criticism of Mikael Grey's article, How to Become a Rock Star Programmer, starts off promisingly enough:

Let's start with the title. There is no such thing as a "Rock Star Programmer," so if you want to become one, you already have problems that reading a blog post can't fix. Rock stars get sex, drugs, parties, limousines, fame, glory, dates with supermodels, and Rolling Stone covers. Good programmers get . . . uh . . . fewer compiler errors. Or fewer runtime errors, depending on which language you're using. So let's not pretend that "Rock Star Programmer" makes any more sense than "lighter-than-air paperweight" or "Rock Star Babysitter."

But the tip he offers is just as flawed as the top ten list he's criticizing:

The best way to improve is to study code that is better than your own. Read good code written by experts, in a variety of programming languages. Study it until you understand how it works and what makes it good. That's it. That's the one tip.

You won't become a better programmer by passively studying other people's code. Similarly, you don't magically become a better writer by reading a lot of books. You become a better writer by.. wait for it.. writing.

Studying code is reasonable advice. It's helpful. But the absolute best way to improve is to write your own damn code! Nothing teaches faster than making your own mistakes, on your own time, on your own terms.

So study "good code*" all you want, but write as much code as you can.

* whatever that is

The Ideal Computer Desk

A few years ago, I did a bit of research on computer desks and decided on this AnthroCart model:

And it's a fantastic computer desk. But its Wife Acceptance Factor (WAF) is abysmal for a few reasons:

• It's absolutely enormous
• It's black
• Its design is better suited to an office than a home

Plus, we just bought a small home in the Bay Area*, and we need to optimize for space. Looks like I'll be selling the Anthrocart.

Which means I'm looking for a smaller desk now.

I had to buy an additional desk when I moved to California, prior to all our stuff arriving. Since we have easy access to IKEA, I went with the IKEA Jerker desk.

You can see the edge of the Jerker in the bottom-most photo of Phil's dog Twiggy. There's something about the Jerker that inspires people: Behold! The shrine to the IKEA Jerker desk!

Although I really do like the Jerker-- and the name alone is worth the 99 bucks-- I'm still researching my options. What is your favorite computer desk, and why?

* Holy crap. That was written in 2004, so add another ~20% appreciation for 2005.

Making Considerate Software

I'm currently re-reading About Face 2.0. I hadn't revisited this book since I bought the original version way back in 1995. The update, which was published in 2003, is a significant overhaul -- and frankly much better than the original. Adding the second author, Robert Reimann, was a smart move. Alan Cooper is a usability legend, but he can be bombastic and overbearing at times. Having another viewpoint in the book helps moderate and refine the message.

One part of About Face that I found particularly compelling was the section on considerate software:

1. Considerate software takes an interest

   To the programmer writing the program, it's a just-in-time information world, so when the program needs some tidbit of information, it demands that the user provide it. The program then discards that tidbit, assuming it can merely ask for it again if necessary. Not only is the program better suited to remembering than the human, the program is also inconsiderate when, acting as a supposedly helpful tool, it forgets.

2. Considerate software is deferential

   Inconsiderate software supervises and passes judgment on human actions. Software is within its rights to express its opinion that we are making a mistake, but it is being presumptuous when it judges our actions. Software can suggest that we not not Submit our entry until we've typed in our telephone number. It should also explain the consequences, but if we wish to Submit without the number, we expect the software to do as it is told.

3. Considerate software is forthcoming

   Most software doesn't attempt to provide related information. Instead, it narrowly answers the precise question we ask it, and it is not forthcoming about other information even if it is clearly related to our goals. When we tell our word processor to print a document, it doesn't tell us when the paper is low, or when forty other documents are queued up in front of us, or when another nearby printer is free. A helpful human would.

4. Considerate software uses common sense

   You can easily find menus offering simple, harmless functions adjacent to irreversible ejector-seat-lever expert functions. It's like seating you at a dining table right next to an open grill. Horror stories abound of customers offended by computer systems that repeatedly sent them checks for $0.00 or bills for $957,142,039.58. One would think that the system might alert a human in the accounts receivable or payable departments when an event like this happens.

5. Considerate software anticipates needs

   A web browser spends most of its time idling while we peruse web pages. It could easily anticipate needs and prepare for them while we are reading. It could use that idle time to preload all the visible links. Chances are good that we will soon ask the browser to examine one or more of those links. It is easy to abort an unwanted request, but it is always time-consuming to wait for a request to be filled.

6. Considerate software is conscientious

   If we rely on a word processor to draft a new MicroBlitz Contract and then try to [save it in the same folder as an existing, but older, MicroBlitz Contract], the program offers the choice of either overwriting and destroying the old contract or not saving it at all. The program not only isn't as capable as [a human assistant who saw the name conflict and appropriately renamed the contracts], it isn't even as capable as [a human assistant who put the two contracts in the same folder]. It is stupider than a complete idiot. The software is dumb enough to make an assumption that because they have the same name, I meant to throw the old one away.

7. Considerate software doesn't burden you with its personal problems

   Software whines at us with error messages, interrupts us with confirmation dialog boxes, and brags to us with unnecessary notifications. We aren't interested in the program's crisis of confidence about whether or not to purge its recycle bin. We don't want to hear its whining about not being sure where to put a file on disk. We don't need to see information about the computer's data transfer rates and its loading sequence, any more than we need information about the customer service agent's unhappy love affair.

8. Considerate software keeps you informed

   We don't want our local bartender to grouse about his recent divorce, but we appreciate it when he posts his prices in plain sight and when he writes what time the pregame party begins on his chalkboard, along with who's playing and the current Vegas spread. Nobody is interrupting us to tell us this information: it's there in plain sight whenever we need it.

9. Considerate software is perceptive

   Software should watch our preferences and remember them without being explicitly asked to do so. If we always maximize an application to use the entire screen, the application should get the idea after a few sessions and always launch in that configuration. The same goes for placement of palettes, default tools, frequently used templates, and other useful settings.

10. Considerate software is self-confident

    Are you sure? Are you really sure? Are you really, really sure?

11. Considerate software doesn't ask a lot of questions

    Choices can be offered in different ways. They can be offered in the way that we window shop. We peer in the window at our leisure, considering, choosing, or ignoring the goods offered to us -- no questions asked. Alternatively, questions can be forced on us like an interrogation by a customs official at a border crossing: "Do you have anything to declare?" Software should never put users through this kind of intimidation.

12. Considerate software takes responsibility

    Most programs are filled with data and settings. When they crash, that information is normally discarded; the user is left holding the bag. Let's say you are downloading your email from a server, when your email program runs out of memory at some procedure buried deep in the internals of the program. The program, like most desktop software, issues a message that says, in effect, "You are completely hosed," and terminates immediately after you click OK. You restart the program, or sometimes the whole computer, only to find that the program lost your email and, when you interrogate the server, you find that it has also erased your mail because the mail was already handed over to your program. This is not what we should expect of good software.

13. Considerate software knows when to bend the rules

    In most computerized systems, there are only two states: non-existence or full-compliance. No intermediate states are recognized or accepted. In any manual system, there is an important but paradoxical state -- unspoken, undocumented, but widely relied upon -- of suspense, wherein a transaction can be accepted although still not fully processed. The human operator creates that state in his head or on his desk or in his back pocket. For example, a digital system needs both customer and order information before it can post an invoice. Whereas the human clerk can go ahead and post an order in advance of detailed customer information, the computerized system will reject the transaction, unwilling to allow the invoice to be entered without it.

    The characteristic of manual systems that let humans perform actions out of sequence or before prerequisites are satisfied is called fudgeability. It is one of the first casualties when systems are computerized, and its absence is a key contributor to the inhumanity of digital systems. It is a natural result of the implementation model. The programmers don't see any reason to create intermediate states because the computer has no need for them. Yet there are strong human needs to be able to bend the system slightly.

Lots of food for thought there. So many applications I use fail even the most basic criteria on this list.

The Value of Repetition.. Again

I was struck by a comment in Steve Yegge's not-so-new blog:

How could you have arrived at [the conclusion that top tech companies do a good job at interviewing] after reading this blog entry? Did you read a different post than the one I wrote? I said interviewing is a terrible mess, and 10% of all interviewers ask the same ridiculous questions to every candidate year in and year out, and I'm not a fan of interviewing the way it's practiced in our industry, on account of it being a "crapshoot", and that even good engineers can wind up not getting offers [because of the inherent randomness and poor selection power of the process most places use.]

I've often been accused of repeating myself. But I firmly maintain that there is absolutely no shame in repeating yourself. In fact, you should be repeating yourself. And here's why. At any given time, only a fraction of the people listening to you will really hear what you're saying. If you repeat your message a few times in different ways, you increase the odds of getting your message across.

Now, that doesn't mean that you should pound on the table and state the same sentence five times:

I understand the value of repetition.
I understand the value of repetition.
I understand the value of repetition.
I understand the value of repetition.
I understand the value of repetition.

Mechanical repetition isn't helpful. It doesn't enhance understanding.

But covering the same topic using a variety of different viewpoints definitely does.

To emphasize my point, I'll just repeat a post I made to my Vertigo blog.

Seth Godin has an interesting insight about repetition:

Of course you're listening. You're the one that's sharing such valuable insight with the universe. You're busy talking about your product or your new book or your organization. You walk into a meeting and there are four impatient people sitting around the table, urging you on, faster faster faster don't waste our time.

So you assume that they're getting it the first time.

They're not.

Odds are, your very clear, very useful ideas are getting garbled in translation. I'll do a post on a topic, and people will trackback to it, announcing that I've said something quite different. I double check my riff to be sure I said what I meant to say, and yes, I did. But they didn't hear me.

It's so tempting to compress your ideas into the smallest possible space and assume that the text or the images or the design will carry the day. But we know that repetition is essential.

The paradox is that the long stuff gets skipped. The long stuff gets ignored. Short books sell better, short commercials get more viewers. So repetition becomes essential. It'll bore your biggest fans, but you can do that (a little).

Sticking to (and building on) your story works if you do it over time.

The problem the Parelli's see in those trying to transition from skilled amateur to expert virtually always comes down to something from the fundamentals that they either never quite mastered, or that they forgot over time. So, perhaps that's one more thing the superior performers do better than the rest of us -- they keep practicing the fundamentals. This fits with the notion that experts practice things that aren't necessarily fun, which can include both the things they still don't do well, AND the non-exciting basics.

Bert Bates (my co-author) is a blackbelt level go player, one of the best amateur players in the state. But when a visiting expert--four belt levels above Bert--showed up at the local go tournament, Bert was surprised to see the guy reading a book on fundamental go problems that Bert had read much earlier in his learning. The expert said, "I must have read this at least a hundred times. My goal each time is to see how much more quickly I can solve all the problems in the book than I did the last time."

I absolutely love practicing the fundamentals. I can never get enough of Hello World, and I happily re-read Code Complete and The Pragmatic Programmer about once a year.

But It's Just One More

The Windows Live Local mapping service is surprisingly difficult to use. It certainly looks simple enough:

Like everyone else, the first thing I do when I encounter a new mapping solution is try my current address. In this case it's my work address. But when I press enter, I get this error:

No results were found. Try another search, or if entering an address, enter it in the Where box. Click help to learn more.

This is admittedly a sample size of one. But everyone I know makes this mistake when using Windows Live Local search for the first time. Yes, the two text boxes are labeled. Sort of. But users won't read anything you put on the screen, even so-called professional computer users like ourselves. There's simply one textbox too many on that form.

It may seem irrational to declare that two of anything is one too many, but consider these stopwatches:

Here's a stopwatch with one button. So this button must start, stop, and reset the time. It's a little overloaded, but like an Apple mouse, at least nobody gets confused. In theory.

Let's add one more button. Maybe one button starts and stops, and the other resets? Or maybe one button starts and the other stops. But which one? It'll take a bit of trial and error to get this to work.

Now we add another button. And an extra sweeping hand. I don't even know where to begin. The complexity just went up exponentially.

This stopwatch has three colored buttons. And no sweeping hand. The colors definitely help: red means stop, green means go. So I'm guessing black is reset.

The last stopwatch illustrates that it is possible to add interface elements without adding confusion. But you have to do it very carefully. If you have to add "just one more.." of any UI element, be sure that you're not adding the one UI element that breaks the camel's back.

Rapid Prototyping Fun

This Gamasutra article highlights some intriguing real world experiences in rapid prototyping:

The project started in Spring 2005 with the goal of discovering and rapidly prototyping as many new forms of gameplay as possible. A team of four grad students, we locked ourselves in a room for a semester with three rules:

1. Each game must be made in less than seven days,
2. Each game must be made by exactly one person,
3. Each game must be based around a common theme i.e. "gravity", "vegetation", "swarms", etc.

As the project progressed, we were amazed and thrilled with the onslaught of web traffic, with the attention from gaming magazines, and with industry professionals and academics all asking the same questions, "How are you making these games so quickly?" and "How can we do it too?"

We lay it all out here. Through the following tips, tricks, and examples, we will discuss the methods that worked and those that didn't. We will show you how to slip into a rapid prototyping state of mind, how to set up an effective team, and where to start if you've thought about making something new, but weren't sure how. We hope these well-tested guidelines come in useful for you and your next project, big or small!

Few of us have the luxury of protyping games, but the principles they outline (embrace failure, use short cycles, etc) are broadly applicable to all software development.

The Login Explosion

I have fifty online logins, and I can't remember any of them.

What's my password? I can't use the same password for every website. That's not secure. So every password is unique and specific to that website. And what's my login name? Hopefully it's my email address, if the site allows that. But which email address?

What's a poor user to do?

Scott Hanselman recently highlighted what he uses to combat the login explosion:

• Microsoft Fingerprint Reader
• Keith's Password Minder
• Foldershare to synchronize the password file across multiple computers

When you need two programs, a bit of hardware, your finger, and a file-sharing web service to solve a problem, you don't really have a solution for the login explosion. What you have is an even bigger problem.

One particular pitfall is the idea that your fingerprint is a secure substitute for your password. This review of a typical USB fingerprint reader illustrates just how foolish that misconception is:

The jelly fingertip peeled off the putty very easily, as you'd expect - clean, cold Silly Putty doesn't stick very well to anything but itself. The gelatine was full of bubbles from my stirring, but the jelly thumb nonetheless had a pretty good complement of print-ridges on it.

Ugly and bubble-y the jelly thumb was, but the scanner loved it. It thought the jelly finger was a real one more than 50% of the time. And since you can attempt recognition about once a second, that means it'd be trivially easy to log in with a thing like this, even with people watching. Trim the jelly so it fits over the end of your real finger, and some very rudimentary prestidigitation will keep your fakery from the attention of onlookers.

I also found it was possible to enroll the jelly thumb as a new finger. It took me four attempts to do it, and its recognition rate wasn't any better than when I was trying to match it to my real finger. But that's still quite good enough to be useable in an, um, covert situation.

Making a gummi fingertip is not difficult, and all current fingerprint readers are fooled by even marginal gummi fingertips a hundred percent of the time. In fact, all biometric systems have significant weaknesses:

Earlier [in 2002], German tech mag c't tested nine fingerprint scanners (six capacitive, two optical and one thermal), plus Panasonic's Authenticam iris scanner, and Cognitec Systems' FaceVACS-Logon facial recognition system. All of the widgets tested were current models, and all came with impressive marketing claims.

Two finger scanners c't tested just didn't work properly. Of the remainder, the capacitive sensors could be fooled in a number of ways if an authorised user hasn't cleaned the sensor after fingering it. A latent print on many capacitive sensors can be revived by, for instance, breathing on it, applying graphite powder, or pressing a plastic carrier bag with water in it up against the sensor.

The graphite powder method works with lifted prints, too - follow your target to the pub, grab his glass after he's finished with it, dust a print with graphite, lift it with tape, and you're ready to go.

Optical sensors didn't fare any better. C't fooled them with silicone fingers made from an impression in wax, and also succeeded with backlit graphite print-copies on tape.

All biometrics can be easily attacked with commonly available materials and widely known techniques.

But the real problem isn't the biometrics. The real problem is relying on a single method of security. Any security expert can tell you that security is based on..

1. What you are
2. What you know
3. What you have

Any authentication method that relies on only one of these things is inherently insecure. If you lose your laptop (something you have), you're still somewhat protected because the thief does not have your password (something you know). Ditto for your cell phone. Switching from only using passwords to only using fingerprints is simply trading one set of insecurities for another.

I have high hopes that Microsoft's InfoCard will be a more viable solution to the login explosion. The InfoCard related MIX06 sessions I've attended so far look promising: it's simple, it does not require any Microsoft servers or software, and it has been developed in conjuction with the rest of the online community. Kim Cameron's Laws of Identity whitepaper has the most comprehensible high-level overview of the problems InfoCard is trying to solve. It's a great read.

Until InfoCard arrives, I guess I'll be clicking the "Having trouble logging in" link. Again.