Coding Horror

From the ACM Code of Ethics:

As an ACM member I will

1. Contribute to society and human well-being.
2. Avoid harm to others.
3. Be honest and trustworthy.
4. Be fair and take action not to discriminate.
5. Honor property rights including copyrights and patent.
6. Give proper credit for intellectual property.
7. Respect the privacy of others.
8. Honor confidentiality.

It's hard to square that with the following hair-raising tale Dustin Brooks sent me via email:

I was looking for a way to back up my gmail account to a local drive. I've accumulated a mass of important information that I would rather not lose. During my search I came across G-Archiver, I figured what the heck I'll give it a try.

It didn't really have the functionality I was looking for, but being a programmer myself I used Reflector to take a peek at the source code. What I came across was quite shocking. John Terry, the apparent creator, hard coded his username and password to his gmail account in source code. All right, not the smartest thing in the world to do, but then I noticed that every time a user adds their account to the program to back up their data, it sends and email with their username and password to his personal email box! Having just entered my own information I became concerned.

I opened up a browser and logged in to gmail using his account information. It still worked.

Upon getting to the inbox I was greeted with 1,777 emails with account information for everyone who had ever used the software and right at the top was mine. I decided to go ahead and blast every email to the deleted folder and then empty it. I may have accidentally changed the password and security question to something I don't remember as well, whoops, my bad. I also contacted google to erase this account as I didn't see a way to delete it myself.

I generally try to give people the benefit of the doubt, but it's difficult to imagine any scenario where this isn't a completely malicious violation of people's trust. This is every user's greatest fear when giving out their login credentials, and to see it realized hurts the trust relationship between users and every other professional programmer working today. I've inadvertently posted my own login information to this very blog before. Fortunately for me, an eagle-eyed reader by the name of Israel Orange didn't abuse that information for his own gain, but instead kindly pointed out my error to me in a private email.

I certainly hope there are more programmers out there like Israel Orange than John Terry. Ethics matter for programmers, too.

I miss Kathy Sierra.

Kathy was the primary author of the Creating Passionate Users blog, which she started in December 2004. Her writing was of sufficient quality to propel her blog into the Technorati top 100 within a year and a half. That's almost unheard of, particularly for a blog with no commercial aspirations. Kathy wrote because she believed in creating better user experiences, for no other reason than the singular joy of sharing her enthusiasm with us.

And it worked. I found her blog by early 2005. I think my first link to Kathy's blog was Who Needs Talent When You Have Intensity? which is still, to this day, one of my favorite posts. It explains a lot about who Kathy is and why she was so inspiring.

I won a nice bonus from Sun for being one of only four instructors in north America to get the highest possible customer evaluations. But what was remarkable about this is that this happened in spite of my not being a particularly good instructor or Java guru. I proved that a very average instructor could get exceptional results by putting the focus entirely on the students. I paid no attention to whether they thought I knew my stuff.

And when I say that I was average, that's really a stretch. I have almost no presentation skills. When I first started at Sun I thought I was going to be fired because I refused to ever use the overhead slides and just relied on the whiteboard, where I drew largely unrecognizable objects and unreadable code. But... I say average when you evaluate me against a metric of traditional stand-up instructor presentation skills. Which I believe are largely bullshit anyway. Assuming you meet some very minimal threshold for teaching, all that matters is that you help the students become smarter. You help them learn by doing whatever it takes. And that usually has nothing to do with what comes out of your mouth, and has everything to do with what happens between their ears. You, as the instructor, have to design and enable situations that cause things to happen. Exercises, labs, debates, discussions, heavy interaction. In other words, things that they do, not things that you do (except that you create the scenarios).

Kathy kicked ass because she wanted us to kick ass. I immediately added her blog to my feed reader. Every new Creating Passionate Users post was the first thing I'd read in the morning, and I was never disappointed.

Until one day in March 2007.

The details are sordid and unpleasant. Kathy's wikipedia entry has a reasonable summary of what happened. It's uglier than most, but I've seen this same pattern play out a few times:

1. Author starts blog
2. Blog becomes wildly popular
3. Popularity causes problem for author
4. Author stops writing
5. Everyone loses

It's been almost exactly a year since Kathy stopped writing. And the world is, in a very small way, a lesser place for it. Kathy was filling her little corner of the world with useful, helpful, and often inspiring information. Just browse the "past favorites" column and imagine what could have filled that space in the last twelve months. Unique voices like Kathy's are what make the internet such a fascinating and wildly poweful Gutenberg press.

Hearing them silenced makes me profoundly sad.

And angry. I'm definitely angry at the jerks who always precipitate these hard decisions.

But I must admit, I'm also a little angry at Kathy, perhaps in a selfish way. Angry that she threw in the towel and locked herself away from the public, away from us, after so many years of positively affecting so many people. I completely understand her rationale for doing so. And it is absolutely her choice to make.

Given the kind of graphic threats Kathy received, I can appreciate the need to be cautious, maybe even to take a hiatus for a while. But when a voice is voluntarily silenced forever, the bad guys have won. Fear wins. I cannot accept this. Intimidation only works if you let yourself be intimidated; terrorism only works if you let yourself be terrorized.

So Kathy, if you're out there, I urge you to come back. We miss you.

I was reminded of all this because Dare Obasanjo recently announced that he's shuttering his blog.

Anil Dash, Mike Arrington, Shelley Powers and myself all find Dare's blog quite useful; he's a unique and insightful voice. I'm sure his nearly 70 thousand subscribers feel the same way. Why shut down something that is clearly enjoyed by so many people? Dare didn't receive death threats, but it's the same basic pattern:

1. Author starts blog
2. Blog becomes wildly popular
3. Popularity causes problem for author
4. Author stops writing
5. Everyone loses

In this case the problems are more subtle, and only alluded to in Dare's sign-off post as a postscript link to The Year the Blog Died.

This year was the first year I considered ending this blog because I'd finally gotten tired of the hassle of people complaining about what I wrote here. The final straw for me surprisingly hasn't been work related although there have been stretching points from disgruntled coworkers who lashed out because I use competing products to people complaining to my management chain and theirs hoping to get me reprimanded or even fired for not toeing the party line. I stand by everything I've written in this blog but I've now gotten enough heat and taken enough inter-personal communication training classes to realize that some opinions are more trouble than they are worth. So every once in a while, I quietly drown a kitten of a half written blog post because I can't be bothered with dealing with the feedback. However that wasn't the breaking point, since I've considered this experience part of "growing up".

What I didn't expect to have to deal with was people back home in Nigeria reading my blog. Or even worse, certain posts from my blog being printed out and republished in Nigerian print magazines. That audience which now includes quite a few members of my family is one I hadn't anticipated and one whose feedback on misconstrued posts is one I take more to heart than the other kinds of feedback I'm used to getting about my blog. This has now introduced a new set of filters I have to apply to my blog posts.

Of course, it is Dare's blog, and he is free to do whatever he likes with it, regardless of what those 70,000 readers might want. He doesn't specify exactly what the problem is, although I have a hard time imagining that his many posts about XML, web APIs, and Facebook are causing problems for his family in Nigeria. Still, I hate the idea that Dare is giving up, that he's conceding to unnamed forces who are intimidating him into silence. It'd be one thing if Dare said that he didn't enjoy blogging, or if nobody was listening. But clearly that's not the case. Dare provided a refreshingly honest and open look at what was going on inside parts of Microsoft, along with some penetrating industry analysis. I'll miss that greatly.

I've never met Kathy Sierra or Dare Obasanjo, although I do feel I know them peripherally through long term readership of their blogs. It's not my place to tell them-- or anyone, really-- what to do.

But I'm absolutely certain that when they stop writing, everyone loses.

Well, you won't technically see me at MIX08 this year. But you will see some very cool top-secret stuff Vertigo created in the keynote.

MIX is by far my favorite Microsoft conference after attending the '06 and '07 iterations. And not just because this year they have a Rock Band competition* and a screening of The King of Kong with star Steve Wiebe. Oh, and did I mention the exclusive MIX party at the Tao nightclub? These things certainly don't hurt.

What I love about Mix is that it ...

• is relatively small and intimate, at around 2,000 attendees.
• seamlessly merges software engineering and design.
• includes a lot of non-Microsoft folks, even those that are traditionally hostile to Microsoft, so there's plenty of perspective.

And it's in Las Vegas. Although I find gambling dreadfully boring (hey, maybe that's another reason why I never got into World of Warcraft), there's always something fun to do.

If you work in the Microsoft stack, and any of that sounds even vaguely interesting -- sign up for next year's MIX when you can. You won't be disappointed. In fact, I guarantee satisfaction. If you attend MIX and don't thoroughly enjoy the experience, then I dare say there's something wrong with you.

A team at Vertigo has been working at breakneck pace over the last two months to build something extra-special that will be shown in the MIX keynote. Of course I can't talk about it until the actual keynote Wednesday morning, but I will give you this one hint: it invokes the power of rock. Details will be available on Vertigo's MIX page in time with the keynote.

Our fearless leader, Scott Stanfield, will also be delivering a blacklisted MIX session on Friday, which expands on what we're showing in the keynote. Be sure to mark this one on your calendar if you're in attendance.

I've been specifically told "it'll be epic; wear your pampers." Duly noted.

* Which Vertigo is totally going to win. You read it here first.

In November 2007 I called these three CAPTCHA implementations "unbreakable":

Google (unbreakable)
Hotmail (unbreakable)
Yahoo (unbreakable)

2008 is shaping up to be a very bad year indeed for CAPTCHAs:

• Jan 17: InformationWeek reports Yahoo CAPTCHA broken
• Feb 6: Websense reports Hotmail CAPTCHA broken
• Feb 22: Websense reports Google CAPTCHA broken

Which means I am now 0 for 3. Understand that I am no fan of CAPTCHA. I view them as a necessary and important evil, one of precious few things separating average internet users from a torrential deluge of email, comment, and forum spam.

So reading that the three best CAPTCHA implementations have been defeated sort of breaks my heart. Even what I consider to be the strongest, Google's implementation, fell hard:

On average, only 1 in every 5 CAPTCHA breaking requests are successfully including both algorithms used by the bot, approximating a success rate of 20%.

A twenty percent success rate doesn't sound like much, but these spammers are harnessing networks of compromised PCs to send out thousands upon thousands of simultaenous sign-up requests to GMail, Hotmail, and Yahoo Mail from computers all over the world. Even a five percent success rate against a particular email service CAPTCHA would be cause for serious concern; with twenty percent success rate you might as well put a fork in that thing-- it's done.

In the meantime, CAPTCHA still serves a useful purpose-- speed bumps that prevent evil bots and the nefarious people who run them from completely overrunning the internet, as Gunter Ollman notes:

CAPTCHAs were a good idea, but frankly, in today's profit-motivated attack environment they have largely become irrelevant as a protection technology. Yes, the CAPTCHAs can be made stronger, but they are already too advanced for a large percentage of Internet users. Personally, I don't think it's really worth strengthening the algorithms used to create more complex CAPTCHAs – instead, just deploy them as a small "speed-bump" to stop the script-kiddies and their unsophisticated automated attack tools. CAPTCHAs aren't the right tool for stopping today's commercially minded attackers.

There's simply too much money to be made in email spam for the commercial CAPTCHA algorithms, regardless of how good they may be, to survive forever. How old is Google's CAPTCHA now? Two to three years old? In the short term, perhaps proliferation and evolution of many different CAPTCHA techniques is the most effective prevention. You should emulate the techniques from the most effective and human-readable industrial grade commercial CAPTCHA, but avoid copying them outright. Otherwise, when they're inevitably broken, you're broken too. CAPTCHA defeating tools are tailored to very specific inputs; if there's little to no monetary incentive, odds are nobody will bother to customize one for yours. My ridiculously simple "orange" comment form protection is ample evidence of that.

Beyond diversification, the deeper question remains: how do we tell automated bots from people-- without alienating our users in the process? How can we build a next generation CAPTCHA that's less vulnerable to attack?

Here's some food for thought:

• Distinguish pictures of dogs from cats
• Choose a word that relates to all the images
• ASCII art
• Solve failed OCR inputs
• Trivia questions
• Math and word problems

At some point, unfortunately, CAPTCHA devolves from a simple human reading test into an intelligence test or an acuity test. Depending on how invasive you want to be, you'll eventually be forced to move to two-factor authentication, like sending a text message to someone's cell phone with a temporary key.

I don't have the all answers, but one thing is for sure: I hate spammers. As fellow spam-hating internet users we all have a vested interest in seeing CAPTCHA techniques evolve to defeat spammers.

If you've used Windows Vista, you've probably noticed that Vista's file copy performance is noticeably worse than Windows XP. I know it's one of the first things I noticed. Here's the irony-- Vista's file copy is based on an improved algorithm and actually performs better in most cases than XP. So how come it seems so darn slow?

Let's start with Mark Russinovich's typically excellent and exhaustively in-depth analysis of Vista's file copy algorithm:

Perhaps the biggest drawback of the [new Vista file copy algorithm], and the one that has caused many Vista users to complain, is that for copies involving a large group of files between 256KB and tens of MB in size, the perceived performance of the copy can be significantly worse than on Windows XP. That's because the previous algorithm's use of cached file I/O lets Explorer finish writing destination files to memory and dismiss the copy dialog long before the Cache Manager's write-behind thread has actually committed the data to disk. With Vista's non-cached implementation, Explorer is forced to wait for each write operation to complete before issuing more, and ultimately for all copied data to be on disk before indicating a copy's completion. In Vista, Explorer also waits 12 seconds before making an estimate of the copy's duration and the estimation algorithm is sensitive to fluctuations in the copy speed, both of which exacerbate user frustration with slower copies.

As Mark wryly notes, file copying is not as easy as it might first appear. As with so many things in life, perception is reality: if users see file copying as slower, it is slower. Despite all the algorithmic improvements, in spite of the superior file copy benchmark results, Vista's file copy performance is worse than Windows XP.

I couldn't ask for a more perfect example of this dirty little human factors secret: perceived performance is more important than actual performance. Fancy copy algorithms won't necessarily help you build a fast progress bar. But understanding how your users' brains work definitely will, as illustrated in Rethinking the Progress Bar:

Humans do not perceive the passage of time in a linear way. This, coupled with the irregular behavior of progress bars, causes human perception of process duration to vary. An understanding of which behaviors perceptually shorten or lengthen process duration can be used to engineer a progress bar that appears faster, even though the actual duration remains unchanged. This paper describes an experiment that sought to identify patterns in user perception of progress bar behavior. The results are then analyzed to classify behaviors that perceptually speed up or slow down process execution.

The study (pdf) used eight progress behavior functions, then tracked users' reactions to each one.

Although all the progress bars took exactly the same amount of time in the test, two characteristics made users think the process was faster, even if it wasn't:

1. progress bars that moved smoothly towards completion
2. progress bars that sped up towards the end

It seems obvious in retrospect why Vista's file copy design failed so miserably, and needed to be patched up with Service Pack 1. It's a textbook example of these principles at work:

1. Explorer waits 12 seconds before providing a copy duration estimate, which certainly provides no sense of smooth progress.
2. The copy dialog is not dismissed until the write-behind thread has committed the data to disk, which means the copy is slowest at the end.

The idea that performance is determined largely by the user's perception rather than actual wall-clock time can be liberating. Like a magician using skillful sleight of hand to perform magic tricks, you can seemingly alter reality. But it can also be frustrating. Even if you get the technical parts right, with hard benchmark data to back you up, subtle human perceptual factors can still negate your work, as those unfortunate Vista developers found out. What's a poor developer to do?

But are both of us missing the real point of owning and using a PC? Can any stopwatch-based measurement of isolated tasks as performed by individual hardware and software components really measure the worth of a technology investment? I don't think so.

This is not a new question for me. Back in the early 1990s, when I was editor of the late, lamented PC Computing, we differentiated our product reviews from those of sister public PC Magazine by focusing on usability. The highly regarded PC Magazine Labs was the quintessential "speeds and feeds" shop. We focused on usability, going to the extreme of spending a small fortune (I still remember the budget battles) building a state-of-the-art usability lab and hiring usability professionals to run it.

Don't make the same mistake the Vista development team did. Think more holistically than mere benchmarks alone. Consider the user's perception of the process, too. I recommend Tog's Maximizing Human Performance as a great starting point.