Coding Horror

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 and resources 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.

I've always felt that repetition helped me learn. And I repeat myself to help others learn.

We're often accused, as software developers, of writing solutions to the same problem over and over. I don't see this as repetition, but practicing the fundamentals:

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.

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.

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.

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.

One of the peculiarities of software development is how rapidly knowledge becomes obsolete. Dan Appleman cited a parable from Lewis Carroll's Through the Looking Glass which illustrates this wonderfully:

'Now! Now!' cried the Queen. 'Faster! Faster!' And they went so fast that at last they seemed to skim through the air, hardly touching the ground with their feet, till suddenly, just as Alice was getting quite exhausted, they stopped, and she found herself sitting on the ground, breathless and giddy.

The Queen propped her up against a tree, and said kindly, 'You may rest a little now.'

Alice looked round her in great surprise. 'Why, I do believe we've been under this tree the whole time! Everything's just as it was!'

'Of course it is,' said the Queen, 'what would you have it?'

'Well, in our country,' said Alice, still panting a little, 'you'd generally get to somewhere else -- if you ran very fast for a long time, as we've been doing.'

'A slow sort of country!' said the Queen. `Now, here, you see, it takes all the running you can do, to keep in the same place.

If you want to get somewhere else, you must run at least twice as fast as that!'

AJAX and Atlas are the hot topics du jour here at MIX06, but will we be using them in five years? Unlikely.

I am all for learning new technology, but immersing yourself in new technologies is merely running as fast as you can to stay in the same place. To get somewhere else, you must run twice as fast. That means studying the topics that won't be obsolete in five years: human factors and design. And that's exactly what my recommended reading list is about. If you haven't read the top 5 books on that list, ask yourself-- am I too busy running as fast as I can?