Coding Horror

Recently, Joseph Cooney and a coworker both recommended the book Designing Interactions to me at the same time. A strange confluence of events that's got to be some sort of sign. I immediately ordered the book.

And I'm so glad I did. It's a wonderful, beautiful book about the history of digital technology design, filled with stunning full-color photographs and illustrations, frequently interspersed with interviews from key industry figures. You can browse the table of contents and download a sample chapter from the book's website. I recommend it without reservation.

I didn't realize it at the time, but the author, Bill Moggridge, is one of the co-founders of the iconic design firm IDEO. His other claim to fame is designing what many consider to be the world's first laptop computer in 1979, the GRiD Compass. Nobody could afford it, of course, but it was an evolutionary milestone in computer history.

IDEO is a true giant in the field of design; just browse through their portfolio and I can practically guarantee you've used more than one product they've designed. IDEO is so influential they've packaged their message into products, too. I already own a few IDEO artifacts. I ordered the IDEO Method Cards back in 2005. I still occasionally flip through them; they're great little nudges to get you thinking about all the different ways design should influence what you're working on.

Last Christmas, without any coaching from me, my wife bought me another IDEO book, The Art of Innovation: Lessons in Creativity. It's a decent read as well. I have yet to obtain a copy of their latest book, The Ten Faces of Innovation: IDEO's Strategies for Defeating the Devil's Advocate and Driving Creativity Throughout Your Organization, but if the length of the title is any indication, I'm sure it's a doozy.

I think IDEO and Moggridge are on the right track: strictly framing technology in service to people. I know it seems obvious, but it's one of those things that bears reminding every so often. Perhaps that's why reading Designing Interactions is so inspiring.

It's hard to imagine now, but in the early days of Microsoft, Bill Gates was an actual programmer. One bit of hard evidence is the BASIC program DONKEY.BAS included with original IBM PCs running IBM DOS 1.10. The history of this weird little program is covered in a 2001 TechEd keynote by Gates himself:

ARI BIXHORN: Well, I am thrilled to be here today, because this week we are celebrating the ten-year birthday of the world's most powerful, productive and popular developer tool. And of course I'm talking about Visual Basic.

Now, to help set the context for just how far Visual Basic has come and really how far the Basic language has come, I'd like to take a step back just a few years and look at an application that was written in Basic. This application, called Donkey.bas was actually written by none other than the gentleman standing to the left of me. Bill, how long ago was it that you wrote Donkey.bas?

BILL GATES: Actually, it was myself and Neil Konzen at four in the morning with this prototype IBM PC sitting in this small room. IBM insisted that we had to have a lock on the door and we only had this closet that had a lock on it, so we had to do all our development in there and it was always over 100 degrees, but we wrote late at night a little application to show what the Basic built into the IBM PC could do. And so that was Donkey.bas. It was at the time very thrilling. So go ahead and show them what that looks like.

Here's a small animation I captured of DONKEY.BAS running in a virtual machine:

Thrilling indeed. The Macintosh folks were suitably unimpressed:

[PC-DOS] came with some games written in BASIC that were especially embarrassing. The most embarrassing game was a lo-res graphics driving game called "Donkey". The player was supposed to be driving a car down a slowly scrolling, poorly rendered "road", and could hit the space bar to toggle the jerky motion. Every once in a while, a brown blob would fill the screen, which was supposed to be a donkey manifesting in the middle of the road. If you didn't hit the space bar in time, you would crash into the donkey and lose the game.

We thought the concept of the game was as bad the crude graphics that it used. Since the game was written in BASIC, you could list it out and see how it was written. We were surprised to see that the comments at the top of the game proudly proclaimed the authors: Bill Gates and Neil Konzen. Neil was a bright teenage hacker who I knew from his work on the Apple II (who would later become Microsoft's technical lead on the Mac project) but we were amazed that such a thoroughly bad game could be co-authored by Microsoft's co-founder, and that he would actually want to take credit for it in the comments.

It's funny to think that DONKEY.BAS is part of Gates' legacy as a programmer. If nothing else, at least he has a healthy sense of humor about his past. The only copy of the source code for DONKEY.BAS I can find has been stripped of any credits by Gates or Konzen. It's a fairly short program, but it's also a painful reminder of how awkward programming was in 1981. Update: Leon was kind enough to send in an original copy of DONKEY.BAS from the DOS 1.1 disks.

During the TechEd 2001 keynote, Microsoft demonstrated a tongue-in-cheek, fully 3D update of Donkey written in the then-beta VB.NET language, to illustrate just how far BASIC had come in the intervening 20 years.

You can still can no longer download the VB.NET version of Donkey from Microsoft. I downloaded it and converted it to Visual Studio 2005 and .NET 2.0 fine. But I couldn't get it to run because of its oddball dependency on DirectX 8.

Donkey .NET is a three-dimensional driving simulator game that demonstrates the new features available to Microsoft® Visual Basic® developers. Written in Visual Basic .NET RTM, this sample uses XML Web services, multithreading, structured exception handling, shaped Windows Forms, and custom-drawn controls. The sample includes the setups for both the game application and an optional XML Web service used with the game. The setups will also install the source code.

I suppose that's another enduring lesson of DONKEY.BAS; the various BASIC implementations have never been known for their stellar compatibility.

Over the last four years, I've basically given up on the idea that .NET is a multiple language runtime.

• The so-called choice between the two most popular languages, C# and VB.NET, is no more meaningful than the choice between Coke and Pepsi. Yes, IronPython and IronRuby are meaningfully different dynamic languages, but they're somewhere on the horizon and far from first-class IDE citizens.

• There's simply too much cognitive friction when translating back and forth between these two very, very similar languages. Semicolons or underscores? Case sensitivity or case insensitivity? Parens or brackets? Arrays that begin at one, or arrays that begin at zero? To-may-to or to-mah-to? It's just not worth the mental effort it costs to keep track of all these nitpicky little differences that can bite you so easily.

• Mixing source code in different languages is awkward at best. You have to segregate each language into its own compilable project. Separate-- but equal. Sort of. Well, mostly.

• Most of the community has settled on C# as the de-facto standard, so you're in for a rough slog of code translation if you want to stick with VB and cleanly integrate commonly available source code libraries into your codebase. And if you want to understand the code you're absorbing into your application (note: this isn't really optional in my experience), you better learn how to read it without a bunch of mental translation gymnastics. And once you've learned how to read and write the language well enough to integrate it, you've come full circle. Like me, you'll be left wondering why you didn't just cut out the translation penalty entirely and stick with one language in the first place.

This is not to say that you can't do multiple language development in .NET. But most of the time, it isn't worth the hassle. It's less painful to move with the herd and choose C# like everyone else does. For the most part, I've learned to suck it up and pretend C# is the only .NET language. I'll even grudgingly admit that explicitly ending lines with semicolons is way better than the mish-mash of carriage returns and underscores we have in VB.NET. But there are still two things that drive me nuts about C#.

The first is the evil of case sensitivity. As an advocate for people over machines, I have to go on record stating that case sensitivity in a programming language is wrong, and will always be wrong. I know the decision is written in stone at this point, and it's never going to change, so I'll leave it at that. It's a religious issue, and we software developers are nothing if not religious. Let's move on.

The second is the C# compilation tax. When working in C#, I'm constantly compiling the solution to ensure that I haven't broken anything. It's a ridiculous productivity tax in an endless loop: Write some code. Compile. Write a little more code. Compile. Change a function. Compile. Rename a variable. Compile. Refactor some methods. Compile. Then compile again, just to be sure. Wait a second.. did I compile this yet? Compile!

Notice a pattern here? I'm going to prematurely wear out my CTRL, SHIFT, and B keys. When coding in C#, I feel like a monkey in a cage that dispenses food pellets when I press CTRL+SHIFT+B. It's a complete waste of time, but you're compelled to do it through perverse incentives in the IDE.

What's particularly sad about this is that, in my experience, most C# developers think manually compiling all the time is a natural state of affairs. Well, it isn't. In VB.NET we have this clever little technology we call background compilation. Background compilation saves you the effort of all that meaningless, repetitive, mind-numbing manual compilation. It's very simple: as you type, imagine all that CTRL+SHIFT+B-ing happening automagically in the background for you.

With background compilation, I know immediately when I've made a mistake. I don't have to wait until the next time I manually invoke the compiler. Let's say I was to type in the following C# code:

string s;
s = 1;

Well, that code looks fine in the editor. Until I compile. Contrast that with the VB.NET equivalent:

Dim s As String
s = 1

The second I finish typing the assignment (e.g., move my cursor off the second line), the statement is flagged as an invalid assignment. No compilation necessary; it automatically appears as an ambient squiggly underline in the background.

This is an admittedly trivial example, but background compilation makes my life so much easier in VB.NET. It reduces the turnaround time between mistake and fix to virtually nothing. And you can do other clever things with it, such as quickly renaming a function or variable to get an idea of where it's being referenced via the stack of compiler errors that appear. If nothing else, it's one less thing I have to remember to do: oh yeah, the C# IDE shows me basic syntax problems, but I gotta compile my C# to see what's really broken. Doesn't that seem like unnecessary work to you? It sure does to me.

Background compilation is something that, unlike case sensitivity, is not written in stone, and possibly could be fixed. It's an IDE feature, not a language feature. Here's hoping the C# team eventually recognizes the massive productivity drain of the C# compilation tax for the average developer. If some developers are masochists who hate productivity, then make background compilation a configurable option they can turn off. They can march off in lockstep, back to their wheel of never-ending CTRL+SHIFT+B pain. More power to 'em.

Personally, I'd rather let the computer do the grunt work of compiling in the background. Freed from the onerous compilation tax, no longer compulsively invoking the compiler every few minutes, I can spend more time concentrating on my code.

I may have accepted the C# penance, but I wish the saints at Microsoft would see fit to grant this one small wish to a converted VB.NET sinner.

The Ghost In The Browser: Analysis of Web-based Malware (pdf) describes how Google is leveraging their overwhelming search dominance to combat browser malware installations. In a blog entry last summer, Matt Cutts said:

Given how much I hate web pages that install malicious software or abuse browser security holes, I'd like it if we did even more to protect our users.

Apparently, they've done even more to protect users since then. Here's a Google search result tagged with the ominous warning "This site may harm your computer":

Clicking "This site may harm your computer" leads to a Google support page. Attempting to click through to the actual website results in an interstitial warning, offering no way to click through:

I think this is a fairly effective method of warning away most rational users from a clearly evil website. Of course, users who desire whatever media, software, or pornography the site is hawking can still type the URL in their address bar. Users will find a way to see the dancing bunnies if they really, really want to, no matter how many warnings and barriers you blast in front of them.

If you want to see what's behind that URL, fair warning: in addition to being outright dangerous for a machine that's not patched to the gills, it's NSFW in a big way. A little investigation showed that it's doing the following:

• Attempts to use the remote data services ActiveX control.
• Shows a spoof HTML page with the text "windows media player cannot play video file; Click here to download missing Video ActiveX object". The download runs setup.exe.
• Runs Javascript with exploit sniffing code.

If you accept that Google wields the immense power of being the de-facto start page for the internet, then maybe this kind of policing effort comes with the territory. To do nothing-- to let these purely evil sites show up in Google results with no warning whatsoever-- would be irresponsible. Although a person might be performing questionable searches to get this page in their results, it's irrelevant. Despite the individual ethics of the person using that one computer, a compromised computer will be used for attacks and spam against everyone.

Still, I'm a little curious. Why does Google deploy the ultimate weapon of search delisting on sites using black-hat SEO techniques to game search rankings, while known evil malware sites get stern warning interstitials instead? I brought up the Google result by doing a direct search on the domain name. The very same search produces no results on live.com or ask.com. Clearly that site has been delisted by everyone except Google. The domain still has a PageRank of four. I applaud the effort, but what value does keeping a site like that in your search index have for users?

Even if your web site is not evil, it's possible for others to inject malicious code into your page if you're not careful. The Google whitepaper provides three external vectors that can turn a good web page to the dark side:

• Compromised webservers can insert malicious code into all HTML pages served
• Pages which allow user-contributed HTML, where the HTML hasn't been properly sanitized
• The use of questionable advertising content, or compromised ad servers

It's scary how many ways this can happen. I strongly urge you to read the whitepaper to get all the gory details.

Google's paper says one in ten webpages contains malicious code. The most direct way to address malware delivered via web pages is to increase the security of the operating system and the browser, so "drive-by downloads" cannot happen without the user's explicit consent. But a problem as large as malware should be attacked on multiple fronts. Search engines are in a unique position to help index and identify malicious webpages, and prevent them from being accessible in search results. It's encouraging to read about Google's architecture for automatically identifying malicious URLs. I don't think it's fair to call this Google policing the web; it's just good, ethical business to filter out the evil.

Asa Raskin, the son of the late Jef Raskin, recently gave a presentation at Google on the work his company, Humanized, is doing. It's largely a continuation of the work of his father. One of the most interesting aspects of Jef's work was zoomable user interfaces. Asa's demo of zoomable interfaces starts at 1:05 in the video. You can interact with the very same flash demo on this page; scroll down to "Launch the Zoom Demo", and be prepared to wait a bit, as it's an 8 megabyte Flash file.

Although popularized by Jef Raskin, Humanized isn't the only company working on zoomable user interfaces; Microsoft has Seadragon:

You can experience the Seadragon technology in Photosynth, which is also being ported to Microsoft's Silverlight. According to Microsoft, zoomable UI has these advantages:

1. Speed of navigation is independent of the size or number of objects.
2. Performance depends only on the ratio of bandwidth to pixels on the screen.
3. Transitions are smooth as butter.
4. Scaling is near perfect and rapid for screens of any resolution.

Zooming user interfaces are rare in current operating systems and applications, but there are a few. You're probably already using at least one zoomable user interface without thinking much about it.

• Most modern mapping sites (Google Maps, Live Maps) allow zooming in and out, with varying degrees of smoothness and fidelity.
• The Expose feature in OS X is a limited form of zooming in and out of the desktop. Vista's Flip3D is a far less useful imitation, but fortunately there is an excellent clone available.
• Ole Eichhorn's company Aperio implemented similar zoom techniques to allow the viewing of terapixel images in the browser. You can dynamically zoom in and out of a 3 terabyte image compressed into 144 gigabytes of data.
• The OLPC Sugar UI heavily leverages the Zoom metaphor in its design.
• Many mobile web browsers, due to their tiny screens, implement zoomable interfaces for navigating the web. The Apple iPhone, the Nintendo DS, and DeepFish for Windows Mobile all use this technique to render web pages.

What really struck me about zoomable UI is how intuitive and usable it is in the right situation. The zooming metaphor is central to the new real-time strategy game Supreme Commander; you're constantly zooming into the battle to take control of individual units, then zooming back out to get a larger, strategic view of what's happening on the battlefield. It's totally natural and completely intuitive. You don't have to think; it just works the way you'd expect it to.

I'm not sure when the mouse scroll wheel became standard equipment on computer mice, exactly, but I'm awfully glad that it did. Zooming is a natural metaphor that people adapt to as easily as they do to scrolling. Zoomable UI is woefully underused today, but I think it should be an integral part of our desktop operating systems in the future.