Best Software Writing – Volume II

Last year, working with Apress, I put together a book called The Best Software Writing I full of great articles about software development from around the web. I was hoping to encourage better writing about software, as I wrote in the introduction:

The software development world desperately needs better writing. If I have to read another 2000 page book about some class library written by 16 separate people in broken ESL, I’m going to flip out. If I see another hardback book about object oriented models written with dense faux-academic pretentiousness, I’m not going to shelve it any more in the Fog Creek library: it’s going right in the recycle bin. If I have to read another spirited attack on Microsoft’s buggy code by an enthusiastic nine year old Trekkie on Slashdot, I might just poke my eyes out with a sharpened pencil. Stop it, stop it, stop it!

Anyway, that book was a big hit so I think it’s time for volume II.

Here’s how it works. Nominate your favorite articles by posting links using the discussion group. All nominations must include the nominator’s full name and correct email address or they will not be considered.

Check out some of the articles that are already there and add your comments. Nominations will be accepted until April 15th.

What’s the Joel Reddit?

The new reddit site at is joel.reddit.coma place for you, my readers, to post links to sites and articles on the web that you found interesting.

In addition to posting and browsing links, you can vote them up or down. The newest links with the highest vote show up on the main “hot” page. There is also a “new” page which lists all the newly-posted links, and some other nifty features which I’m sure you’ll discover soon enough.

What’s the point?

The main idea is to share interesting links from around the Internet with other Joel on Software readers and with me. Anything is fair game… post whatever you want, but use your voting power to vote for things you found interesting (and vote down spam, duplicates, and boring things). If all goes well, a bunch of interesting stuff will float to the top.

Check out my thing!

Every day I get at least a half dozen emails of the form, “check out my thing!” with a URL for some startup or widget or interesting article that someone wrote. I love ’em but I don’t always have time to read them and it’s vanishingly unlikely that I will ever link to them, because that’s not really what this site is all about. Well, the Joel reddit will solve this problem. If you wrote something interesting that you want to publicize, just put it up on the reddit. If it really is interesting, other people will vote it up and it will get noticed. If it isn’t interesting, go work on making it more interesting and post it again.

OK, Stop Asking Question and post some interesting links!

Special thanks to Alexis, Steve, and all the kind folks at for setting this up, and special thanks to Alexis for drawing “Blowhard Pundit Joel,” with microphone and podium, to match their cool reddit alien mascot.

Software Development Productivity Awards

Fog Creek Copilot won the Software Development 16th Annual Productivity Award in the “Utilities” category. All credit for this cool award goes to the interns who developed it in one summer: Tyler, Ben, Michael, and Yaron!

FogBugz 4.0 won the Productivity Award in the “Defect Tracking, Change, and Configuration Management” category. Congratulations to the whole FogBugz team!

Productivity Awards are sort of like runners-up for the Jolt Awards… there are three Productivity winners in each category but only one Jolt. In the Utilities category, the Jolt went to TechSmith for Camtasia, the demo-making software we use and love here at Fog Creek (check out the flash demo of FogBugz we made with Camtasia last year).

Software Development magazine, which gives the awards each year, started out as Computer Language, and now they just announced that they are merging with Dr. Dobbs Journal and taking over the Dr. Dobbs name. Eric Sink’s blog post about the eventual death of developer magazines seems prescient.

Usability in One Easy Step (First Draft)

Bad usability in the design of aircraft controls can result in what is cheerfully referred to as CFIT: Controlled Flight Into Terrain.

The usability of your product may not be quite as critical. If you’re lucky, the mistakes you make in usability design will merely cause people to lose limbs, or, heck, even just thumbs. No biggie!

In fact if you’re extremely lucky, your unusable design will do nothing more than make people sad. They’ll try to accomplish things, and either fail, or struggle, and for very real reasons this will literally make them unhappy. I’ll explore the psychological reasons for that in a future article, but for now, suffice it to say that making the users of your design unhappy is not likely to be precisely the result you were looking for, unless you’re designing a French film.

So, usability. That’s really at the heart of good design, and I’m going to spend a lot of time on it.

The good news is that I can teach you everything I know about usability while standing on one foot. Ready? Here we go:

Something is usable if it behaves exactly as expected.

That’s it! That’s the whole story! As Hillel said, all the rest is commentary.

Let me run a little example by you.

Which is Easier to Use: Windows or Mac?

When you’re designing a product for humans, it helps to keep imaginary users in mind. The more realistic the imaginary user is, the better you’ll do thinking about how they use your thing.

My imaginary user is Pete.

Pete is an accountant for a technical publisher who has used Windows for six years at the office, and a bit at home. He is fairly competent and technical. He installs his own software; he reads PC Magazine, and he has even programmed some simple Word macros to help the secretaries in his office send invoices. He has a cable modem at home. Pete has never used an Apple Macintosh. “They’re too expensive,” he’ll tell you. “You can get a 3.6 GHz PC with 2 gigs of RAM for the price of…” OK, Pete. We get it.

One day Pete’s friend Gena asks him for some computer help. Now, Gena has a Macintosh iBook, because she loves white computers. When Pete sits down and tries to use Gena’s Macintosh, he quickly gets frustrated. “I hate these things,” he says. He is, finally, able to help Gena, but he’s grumpy and unhappy. “The Macintosh has such a clunky user interface.”

Clunky? What’s he talking about? Everybody knows that the Macintosh has an elegant user interface, right? The very paradigm of ease-of-use?


On the Macintosh, when you want to resize a window, you have to grab the bottom right hand corner to resize it. On Windows, you can resize from any edge. When Pete was helping Gena, he tried to widen a window by dragging the right edge. Frustratingly, the whole window moved, rather than resizing as he expected.

On Windows, when a message box pops up, you can tab to a button and hit the space bar to press that button. On the Mac, space doesn’t work. When Pete got alerts, he tried to dismiss them using the space bar, like he’s been doing subconsciously for the last six years.

The first time Pete tried that on the Mac, nothing happened. Without even being aware of it, Pete banged the space bar harder, since he thought that the problem must be that the keyboard did not register his tapping the space bar. Actually, it did—but it didn’t care! Eventually he used the mouse. Another tiny frustration.

Pete has also gotten into the habit of using Alt+F4 to close windows. On the Mac, this actually changes the volume of the speakers. At one point, Pete wanted to click on the Internet Explorer icon on the desktop, which was partially covered by another window. So he hit Alt+F4 to close the window and immediately double-clicked where the icon would have been. The Alt+F4 raised the volume on the computer and didn’t close the window, so his double click actually went to the Help button in the toolbar on the window which he wanted closed anyway, and that immediately started bringing up a help window, slowly, so now, he’s got two windows open which he has to close.

Another small frustration. But, boy, does it add up. At the end of the day, Pete is grumpy and angry. When he tries to control things, they don’t respond. The space bar and the Alt+F4 key “don’t work”—for all intents and purposes, it’s as if those keys were broken. The window disobeys him when he tries to make it wider, playing a little prank where it just moves over instead of widening. Bad window. Even if the whole thing is subconscious, the subtle feeling of being out of control translates into unhappiness. “I like my computer,” Pete says. “I have it all set up so that it works exactly the way I like it. But these Macs are clunky and hard to use. It’s an exercise in frustration. If Apple had been working on MacOS all these years instead of mucking about with video iPods and other toys, their operating system wouldn’t be such a mess.”

Right, Pete. We know better. His feelings come despite the fact that the Macintosh really is quite easy to use—for Mac users. It’s totally arbitrary which key you press to close a window. The Microsoft programmers probably thought that they were adding a cool new feature by letting you resize windows by dragging any edge. The Apple programmers probably thought they were adding a cool new feature when they let you move windows by dragging any edge.

All those flame wars you read on the OS bigot websites about user interface issues focus on the wrong thing. Windows is better because it gives you more ways to resize the window. So what? That’s missing the point. The point is, does the UI respond to the user in the way in which the user expected it to respond? If it didn’t, the user is going to feel like they can’t control the interface, and they’re going to be unsuccessful. That’s all there is to it. Something is usable if it behaves exactly as expected. Tattoo this on your forehead. Backwards, so you can read it in the mirror.

If you follow along in future articles, you’ll see that just about everything I can teach you about usable design is going to relate back to this simple rule, so if for some reason aliens land in your garden tonight and whisk you away to the planet Kij8zxwrk, where you have no access to the Earth’s Internet because TCP/IP doesn’t work well when packets take hundreds of years to arrive, you already know enough to get a job as a pretty decent usability designer.


Usability in One Easy Step

“Bad usability in the design of aircraft controls can result in what is cheerfully referred to as CFIT: Controlled Flight Into Terrain.

“The usability of your product may not be quite as critical. If you’re lucky, the mistakes you make in usability design will merely cause people to lose limbs, or, heck, even just thumbs. No biggie!”

Read on: Usability in One Easy Step

(You may recognize this article as an extensively rewritten version of beginning of my book UI for Programmers. Indeed, I’m in the process of expanding and revising most of that book, and that’s what you’re reading here.)

A lot of travelling

Somewhere in the world, there’s a conference organizing school, and they must teach you there that all conferences have to be held during March. This month I’ll be in California more than New York:

First stop: O’Reilly ETech in San Diego, where I’ll give a quick status report on the state of affairs in UI design. At another session, I’ll give some tips on usability testing.

Then to Austin for SXSW where I’m on some kind of panel entitled Sink or Swim: The Five Most Important Startup Decisions. Here’s a good startup decision: work on your products instead of hanging out at “interactive festivals” in Texas.

Next, it’s back to California for SDWest 2006 where Tyler and I will take questions at a screening of Aardvark’d and, hopefully, bring home some lucite beverages.

After a few minutes at home, I’ll be appearing at Eclipsecon (Is Java the new Cobol?) and visiting Y Combinator.