Caller: “My computer is a fire risk.”

Me: “What makes you say that?”

Caller: “It gets hot. There are papers near it.”

Me: “If you’re worried about it, you can move the papers away.”

Caller: “I am moving the papers, but you must send someone to look at it.”

[More back-and-forth, in which caller reiterates that her computer is "a fire risk" and says the situation is urgent. A technician is dispatched, who eventually reports back:]

Technician: “You know that computer that was a fire risk?”

Me: “Yes?”

Technician: “She meant it was on fire.”

This isn’t the first time I’ve heard about such mistakes, either. Rinkworks’ “Computer Stupidities” sub-site has an entire page devoted to instances of computers smoking or catching fire (or people being worried that they might). One in particular involves a tech telling a college student over the phone, “Unplug the computer right now. Your paper is lost. Your floppy drive is lost. If you’re lucky the Mac will be OK. Unplug it now.” The student doggedly insists, “But I don’t want to lose my paper!” Then the tech hears someone in the background (presumably the student’s roommate) scream. Then the dorm fire alarm goes off.

For those who need to be told, I am willing to state, as a computer professional with 15 years of experience in hardware, software, system administration, troubleshooting, and repair:

If your computer or computing device ever emits smoke, sparks, or flame: Unplug it immediately. Do not bother with “proper shutdown procedure”; simply assume all data on it is completely hosed and start emergency fire-prevention procedures. Unplug its power. If it’s a laptop, also yank out its battery. If signs of combustion continue, use a fire extinguisher or water, as appropriate.

Unplugging it means there’s no more electrical power going to it. Many times, that’s enough to kill the combustion right there — if you were quick about it, the fire may go out on its own at this point. If it doesn’t, it is at least no longer an electrical fire. That means if you haven’t got an ABC fire extinguisher handy, you can still just throw water on the thing, without risking electrocution.

Once it’s been smoking or sparking, the device is ruined anyway. Understand that all your data is gone. (This is why it’s important to have complete, current backups.) The important thing to do is to make sure the fire doesn’t spread. Don’t panic, and don’t waste any time trying to shut down carefully or in the usual manner — that will just prolong the fire.

Remember, where computing devices are concerned, if it smokes, it is toast. Or it is fried; pick whichever image works better for you. If you let it keep running once it’s on fire, all you’re doing is putting yourself at risk. Don’t do it.

(Of course, a company like that isn’t about to hire any QA testers, so you folks haven’t got the option of working for them. And I’m not a QA tester, I’m a developer. So the rest of my advice is pretty much aimed at fellow devs — but that doesn’t mean I don’t respect you QA folks. Seriously, y’all deserve a lot more respect than you get, and I love it when you make my life easier by finding my bugs for me.)

The skills, talents, and basic mindset that make a good developer are entirely different from the ones that make a good QA person. Asking one to do the other’s job is a mistake as fundamental as expecting graphic designers and accountants to swap places. Let me explain:

Developers hate repetition. We hate having to repeat anything more than once or twice; that’s why some of us become developers in the first place: because we can write programs that automate repetitive drudgery, and hence banish it from our lives.

It’s not just repetitive tasks, either. A good developer will also have a strong aversion to repetitive code and data. If two procedures differ by only one or two minor details, a good developer will combine them into one, and parameterize it, or otherwise figure out a way for the machine to make the decision. (A poor coder, by contrast, will produce “copy-and-paste code” that’s scorned by more advanced devs, because it’s more brittle as well as being less elegant.) If data must be stored somewhere, the prevailing wisdom is to keep it in just one place — “Don’t Repeat Yourself” is the maxim.

But a good QA checker has to deal with repetition all the time. It’s a fundamental part of their job. Run this test plan — this particular series of actions — over and over again, on each of the platforms we need to test on. Log every step of it, so that if something does go wrong, we can reproduce it.

Then, once the coder has checked in the changes that (hopefully) will fix the bugs you found… do it all over again. Just the exact same way. On every platform.

This is a coder’s nightmare. A developer’s natural response to this situation is to write some kind of automated QA-testing software. Of course, that software itself will then have to be checked for bugs before you could possibly rely on it… and you can’t trust your software to find its own bugs.

In the absence of such software, asking a developer to do bug-checking means asking them to do something that goes against their very nature. You can force them to do it, but they’ll never be really good at it.

Of course, all of that is totally leaving aside the obvious point that asking someone to find the flaws in their own work means asking them to see past their own mental blind spots — a developer’s test plan will be based on the same assumptions as their code, without the coder even realizing it. And that’s to say nothing of the obvious implications once you put the human ego into the picture. Human beings are flawed, and too many see “find the bugs in your own code” as equivalent to “show me all the ways you suck”.

Don’t ask a developer to do QA. Development and QA testing are fundamentally different disciplines, with completely different skill-sets and personality requirements. A developer can no more cover for a QA tester than a QA tester could fill in for a developer.

And if you’re a developer at a company that wants you to do your own bug-checking? Your employer thinks what you do is so similar to bug-checking that you’ll be good at it. They think they can cut corners on quality, and pay you one salary to do two jobs at once (including one job that it is in your nature to hate). If you can’t make them see reason, it’s time to brush up your résumé.

Hackers* use the word “state” to describe “information being maintained in non-permanent memory”, whether that memory is in a human skull or a computer’s RAM chips. In fact, that ambiguity over exactly where the state is being maintained is one of the word’s strengths — as the browser-tabs example shows, there’s getting to be less of a distinction between the two. The stuff in my browser’s tabs is a reflection of what’s in my own brain, and a nearly-seamless extension of it.

Like every other web developer, I recently got a message from Firefox saying it needed to upgrade. (Because security researchers found yet another hole in Adobe Reader.) Despite the fact that I had over a dozen tabs open, I knew I wouldn’t have to worry about performing the upgrade, because Firefox would remember all my tabs and reopen them after restart. It’s basically a momentary hiccup in my workflow; I can start the upgrade and then use that 30-second break to refill my teacup or go to the bathroom. Come back, sit down, close the spare “You’ve just successfully upgraded Firefox” tab, and just keep working.

Compare that with Windows Update.

For one thing, I can no longer in good conscience advise people to allow Windows Update to automatically install things. Not after Microsoft used it to push “Windows Genuine Advantage”. With Firefox, a security update really is just a security update, not an excuse to push crapware on one’s customers. With Windows Update, I need to scroll through the list of updates and make sure they’re not sending me something I don’t want (but which I can never uninstall if I accept it once).

More importantly, though: You never know when a Microsoft security update will include some component that forces a reboot. Sometimes, you’ll just get a message that your update isn’t complete until you restart, and would you like to do that now? Other times, you get the annoyingly insistent dialog box that pops up every five minutes, nagging at you to restart your machine. And it won’t go away until you restart. Trying to get anything useful accomplished between that thing’s interruptions is like trying to concentrate with a Harrison Bergeron-style mental handicapper on. Which means that before you even start the process, you’d better be ready to save and close all your work in every single application.

Is it any wonder people hate installing Windows security patches?

The problem is that if you make security updates annoying, people will try to avoid them. And one of the biggest annoyances these days is breaking people’s train of thought. Now that half of my train of thought is in the computer — in “state” that the software is maintaining for me — making the software continue to maintain it across sessions turns out to be a big win.

The E Text Editor is another example of an application that makes it really easy to leave state in the computer’s memory instead of cluttering up your own wetware with it. E’s philosophy is to never discard data unless the user explicitly requests it. It takes the concept of an Undo history far beyond what most people are used to.

Back in ’90s, people got used to having an “Undo button”: you could reverse one action. Then we got the “Undo history”: you could work backward through multiple steps of undo. Finally, we got the “Undo/Redo history”, which allowed one to step forward as well as back in that timeline… but it was still just a line. If you went back 50 steps, then did something new — something different from stepping forward — those 50 steps were all immediately discarded.

E doesn’t discard information so casually. If you do something new, you now have a new branch in the history of your document. It has an “Undo/Redo tree”. (This results in a lot of data being maintained on your hard drive. So what? Hard drive space is cheap. Way cheaper than human attention, which means trading off a bunch of disk space in order to maintain some human attention is a very good deal.)

And, of course, it maintains this state across sessions. If I’ve been working on a complicated image in Photoshop for a few hours — or for a week or two, without closing the program (and hence not applying any Windows security updates, because they might force a reboot!) — one of the last things I want to do is close that file unless I’m positive that I won’t ever feel like going back to a previous version of it. (This is why graphic artists get so used to hitting “Save a Copy” a whole lot.) The moment I close the file, even if I leave Photoshop itself open, I’ve lost that history.

Not so in E. I can close the program, apply my Windows patches, then reopen E… and it will reopen the files I had open when I exited it, with all that Undo/Redo tree-history still there.

And this also means that shutting down and restarting E is an easy action. It has no ill effects. I can do it any time, and not have to worry about what I’m losing. Which means that if E ever comes out with any security patches, I won’t be at all worried about applying them.

Having nothing to lose by a shutdown makes your program a lot more likely to be upgraded.

* In case it isn’t already obvious, I’m using the word “hacker” to mean “a computer programmer who loves programming for its own sake, not someone who’s just punching a clock to pay the bills”. This is similar to the programmer-enthusiast culture’s classical definitions that include “A person who enjoys exploring the details of programmable systems and stretching their capabilities” and “A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.” It should be very obvious that I don’t mean someone who breaks into computer systems.

1. Obviously, it wastes the user’s time and may even annoy them.
2. It also contributes to the general problem of “too damned many dialog boxes in computing”. This is subtly but importantly different from the previous point: It trains the user to unthinkingly click the default option in any dialog box, just to keep it from wasting their time.
3. Finally, it may actually hinder the user’s ability to leave your program. Look at this page by Joel Spolsky, and search for “exit Juno”. A user thought the “Are you sure you want to exit?” dialog meant that the computer was advising her that there were ill effects from doing so.

Okay, that last one seems like sort of an edge case, right? But even the first two items are enough reason to pay attention to when you should — and shouldn’t — ask the user to confirm something.

My proposal: Only ask a user for confirmation when the action was initiated by a single click or keystroke, and it has some kind of bad effects. Yes, this means that any time you ask someone to confirm whether they want to exit your program, and they have already saved all their work, you just wasted their time. This one’s particularly prevalent in the gaming world, I’ve noticed: Even if you’re in between games, and your scores are all saved — meaning the worst possible consequence of exiting the game is that you’ll have to start the application again — most games will show you a “Do you really want to exit Game Name?” dialog anyway.

MS Word gets this exactly right. If your document hasn’t been changed since the last time you saved it, then exiting the program has no ill effects. If you click the little X, or press Alt+F4, MS Word won’t even bother to ask you “Are you sure?”; it’ll just exit with no muss and no fuss. It’s only if you have some unsaved work that you’ll see the “Do you want to save your changes?” dialog. And if your document already has a filename, Word doesn’t bother to prompt you for a new one; you only get the “Save As…” dialog if the document doesn’t yet have a filename.

The program only bothers the user if it has to; if it can figure things out on its own, it does. Just the way it should be.

If you’re writing another application — I don’t care whether it’s whether it’s a web application, Rich Internet Application, desktop application, or smartphone application — please take a hint from the way MS Word handles confirmation questions. Don’t make your app be the software equivalent of “that guy”.

1. When someone says it to you, you know how to spell it. This means that if my friend wants to tell me about your site at a party or a club or out on the street somewhere, she doesn’t have to spell it out for me. She can just say your site’s name, and I immediately know how to type it into my browser.
2. When you see it written, you immediately know how to pronounce it. This is the other side of the coin, and it matters when I read about your site in print and then want to tell a friend about it. In fact, if your site’s name is sufficiently opaque, I could read about it, visit it, sign up, and use your service for months… and still not know how to tell a friend about it without having to say awkward things like, “Ummm… Zip-tick? something like that? I don’t really know how to pronounce it, I just know it’s spelled X-Y-P-T-I-Q.”

Marc Hedlund writes about Why Wesabe Lost to Mint, and manages to miss part of this point:

Mint was a better name and had a better design – both of these things are true, but I don’t believe they were primary causes for our company to fail and for Mint to be acquired. Mint’s CEO likes to talk about how ridiculous our name was relative to theirs, but I think the examples of Amazon, Yahoo, eBay, Google, and plenty of others make it plain that even ludicrous names (as all of those were thought to be when the companies launched) can go on to be great brands. (emphasis in original)

He cites “Amazon, Yahoo, eBay, Google” as examples of “ludicrous” names, but he misses the fact that all of them meet both of the requirements above — and Wesabe doesn’t. I’m assuming it’s pronounced “wee-SOB-ay”, but it could just as easily be read as “wee-SAYB” (rhymes with “babe”) — and I’m guessing it’s a mash-up between wasabi and “we sabe“, where sabe is the Spanish word for “to know”, and the basis for the English verb “to savvy”.

But that’s just a guess.

Of course, you already know how to spell it, but imagine someone told you about “a new site called /wee-SOB-ay/”… how would you guess it might be spelled? Ideas that come to my mind are: wiisabe, weesabay, weesobbe (possibly with accent on the E in the site’s logo); and “Just tell me how it’s spelled, already!”

Note that Google got its name from the mathematical concept of a googol: 10¹⁰⁰, a very large number. But they deliberately changed the spelling, so people would be more able to tell each other about it, and more able to correctly type in what they’d heard.

A lot of people have been, effectively, pointing and laughing at Stoll’s failed prediction. I’d rather consider it a cautionary tale: The man who was so totally wrong wasn’t just a random pundit who didn’t know what he was talking about. He was Clifford Stoll — author of The Cuckoo’s Egg, a man who had been online for 20 years at a time when most people were just beginning to hear that there was a such thing as the World-Wide Web, and the man who traced German cracker Markus Hess through umpteen layers of insecure computer systems and networks.

In short, the man knew what he was talking about. He wasn’t a Senator Ted Stevens. If he could be so wrong, how much faith can I place in my own predictions about where the Internet’s headed?

But wait, there’s more — how wrong was he? Sure, Stoll claims that “no online database will replace your daily newspaper”, which has turned out to be completely false. But how about “no CD-ROM can take the place of a competent teacher”? No matter how interactive the CD, it can’t substitute for a good human teacher’s ability to guide and nurture a student’s intellect. (Not without AI, which is still at least 20 years away — just like it’s been for the past 50 years.)

And maybe you think it’s obvious that CD-ROMs can’t replace real teachers. But there have been, and there still are, people who claim their CDs are just as effective as face-to-face teaching methods — or even more effective.

Stoll gripes about the problems of Usenet. Okay, the main bulk of Internet conversation has moved to blogs and comment threads, but his words still apply: “Every voice can be heard cheaply and instantly. The result? Every voice is heard. The cacophony more closely resembles citizens band radio, complete with handles, harassment, and anonymous threats.”* There’s a reason why many of my friends say, “Never waste your time reading the comments.”

I’ve written before about the effects of “harassment and anonymous threats”. That was just last year, and I doubt that all the anonymous threateners have suddenly left the Internet.

It’s very easy to look at Stoll’s rant and get distracted by the petty details: “Usenet? Hah! How archaic!” But that’s just a way of trying to remain comfortable, and ignoring the ways in which things haven’t changed one bit. Because the problems of anonymity aren’t technological problems; they’re problems of human nature.

But even in the places where Stoll was wrong — demonstrably, ridiculously wrong — it does me no good to simply point and laugh. Instead, I’d rather ask myself, “Could I have done any better?” Stoll claimed that online shopping would never take off:

[Internet hucksters promise that] We’ll order airline tickets over the network, make restaurant reservations and negotiate sales contracts. Stores will become obsolete. So how come my local mall does more business in an afternoon than the entire Internet handles in a month? Even if there were a trustworthy way to send money over the Internet — which there isn’t — the network is missing a most essential ingredient of capitalism: salespeople.

He’s wrong on almost every particular; the only one that might possibly be an exception is “negotiat[ing] sales contracts”. Aside from that? I’ve lost track of how many restaurant reservations I’ve made online and how many airplane tickets I’ve bought online; over the past ten years, I’m quite positive that I’ve done those things far more often online than by “traditional” methods. Even if you don’t consider PayPal to be quite trustworthy, online credit-card transactions are now safe and secure.

And salespeople? Most of the time, I can do without them. I can’t help but remember the last time my girlfriend and I visited a Victoria’s Secret; after being approached by 5 different salespeople in as many minutes, we left the store in frustration at being interrupted and distracted so much — to the point that we couldn’t even browse the merchandise in peace!

Great, so Stoll was totally wrong about online shopping. If you’d asked me about it in 1995, what would I have said? Would my predictions have been any better?

And more to the point: What am I predicting right now? And how wrong am I? And how can I learn from Stoll’s mistakes — or my own — and make better predictions?

That’s the real take-away from Stoll’s article. And those are question I don’t have the answers for yet. (If you’ve got answers, leave a comment and tell me!)

* All quotes from Newsweek edited to fix simple spelling mistakes.

It might be a welcome trend, if the replacement widgets people were building had more functionality than the OS-native ones that are available for free in any other context. But usually, the widgets I see in these frameworks have less than half the functionality of the things they try to replace. I’m going to pick on scroll bars for now, because I’ve seen them horribly mangled too many times.

To start with one aspect of scroll bars that we often take for granted: Can you guess which of these text boxes contains more text?

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Quisque est est, luctus quis suscipit et, lacinia ac odio.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco.



Of course you can; you don’t even need to guess. The one on the left has more, and you can tell immediately because the movable slider on its scrollbar is smaller. This is a feature you get for free from the native OS widget, and one I have never seen implemented in a Flash, AIR, or similar interface.

Here are all the things a native scrollbar does. I absolutely guarantee you, if you’ve reinvented a scrollbar, your implementation is missing at least two of these features:

1. As mentioned above, the slider object changes size automatically, to give a general impression of how much content the scrollable area contains.
2. The arrows at the top and bottom of the scrollbar are clickable, and clicking them once will move the content up and down by a small amount (typically 1 or 2 lines).
3. Clicking and holding the top and bottom arrows will cause the content to scroll more rapidly.
4. Clicking and dragging on the slider will scroll the content smoothly to any position the user chooses. (Yes, I have seen scrollbar implementations in which the slider was not a draggable item!)
5. Scroll wheel support: If the user’s hardware includes a scroll wheel, scrolling it will move the content up and down. This is many users’ preferred method of scrolling content these days, and yet it’s totally ignored by over half the Flash interfaces I’ve encountered in the past year. I’ve bolded it because it’s the one that gets so egregiously ignored.
6. The “gutter” in between the arrows and slider is also clickable. Clicking on it once will scroll the content up or down by, roughly, the size of the visible area (a “page”, as it were).
7. Of course, clicking and holding in the “gutter” area will repeatedly and rapidly scroll the content. (This is rarely apparent unless you’re dealing with a tall scrollable area and a fairly long document. Try loading a 25-page or longer document into a word processing program, and set the program to full-screen.)
8. When the content is scrolled (by whatever method), the slider will move up or down to indicate how far from the beginning or end you are. (Essentially the converse of item #4: Moving the slider scrolls the content, and scrolling through the content moves the slider.)
9. The arrow buttons and the gutter area give a visual indication when they’ve been clicked, so the user has better feedback. (This is one of those little things that makes the user experience so much better. It’d be so easy to do, and yet I’ve seen about 2 Flash scrollbars in my life that have bothered with that feature.)
10. If you set your cursor focus on the scrollable area, using the up and down arrow keys will scroll the content. Either the Home and End or Ctrl+Home and Ctrl+End keystrokes will move directly to the beginning and end of the content. The PgUp and PgDown keys may also move the content by an amount similar to clicking in the gutter.
11. The scrollbar — including its arrows, gutter and slider — looks just like every other scrollbar on the user’s computer. The user can immediately identify the items and finds them familiar.

Even if you have done a smashing job of replicating the first 10 points on this list, you simply can’t get the final one in an AIR, Silverlight, or Flash interface. If your whiz-bang interface platform provides some other benefit, then dropping that last feature might be worth it.

But it’s no excuse for dropping all the other stuff. Most non-native scroll bars I’ve seen support only 3 or 4 of these features, which means anyone who normally uses any other ways of interacting with scrollbars winds up cursing and deciding that this broken implementation is cheap and chintzy.

Which it is. If you’re going to reimplement the wheel, at least make it something that will roll smoothly.

So, following good software development processes, you first write a couple of tests:

UserTypeOne gets features A, B, and C
UserTypeOne does not get features D, E, or F
UserTypeTwo does not get features A, B, or C
UserTypeTwo gets features D, E, and F

Then you write some code that meets these tests, including creating a pair of mock users with the new flag set in both possible ways. You run the tests, and they all pass. Yay! Your new feature is ready!

Except that, of course, the moment you check this code in, you find that suddenly, nobody can log in any more. After all, the new flag is supposed to be mandatory, and that requirement is reflected in one of the changes you made to the login code. But the only users that have the NewFlag at all are the ones you just created in your fixture.

Sure, this will probably get caught before it goes live. Even if your entire QA department is asleep at the switch, if just one person in your organization tries to run even the most rudimentary tests, they’ll get back an error message. But “it didn’t get pushed to production” is only the most minimal level of success; I’d like to look at how you, the coder, could have prevented this problem. How could you keep this error from even getting checked in (and thus breaking the build and flat-lining your co-workers’ productivity for a few hours)?

The way a real QA department would spot this problem is regression testing. But it’s not reasonable to ask every coder to do a full suite of regression tests before every commit.

The real failure, of course, is that you made a change that you didn’t test. But saying “force programmers to write better tests” is not a viable answer; people are imperfect. You might as well mandate “developers may not check in any code that contains bugs” as one of your organization’s rules.

I don’t have a good answer to this problem. Asking developers to also be QA people is completely impractical. The current solution seems to be “developers sometimes check in code which breaks the build, and blocks people’s productivity for a while”. (Distributed SCM can help mitigate this.)

Is there something QA people know that developers don’t, that would make an easy solution that we could adopt?

However, Livejournal is very customizable. It has 31 different “layouts”, each of which can then be further “themed” by application of CSS. This means that a user viewing a given journal, community, or single post, at a given time, may receive an HTML document containing any of 31 different DOM structures.

This means that finding a post’s author, or title, or even just a single post or comment, is not a straightforward process. I’ve set myself up a Ruby script that downloaded my “friends” view, a representative entry with lots of comments, and my own journal view, thus giving me a set of 93 fixtures that I can test against. The Ruby script also tweaked each fixture in the process of spooling it to my hard drive, by adding the proper calls to JSUnit files.

At the end of each document’s <head> element, there’s a call to jsUnitCore.js. Then, at the end of each <body>, I add a call to the lj-content-sieve.user.js script itself, as well as a set of test files that depends on which fixture this is. Every fixture gets an ljcs-global-tests.js call added to it — that file contains tests that should work anywhere, regardless of what sort of page you’re on.

Then all the “friends” page fixtures get an ljcs-friends-tests.js file, which tests operations that should happen on every friends page. For example, determining which entries need to be deleted. (In contrast, single-entry pages get ljcs-entry-tests.js, and the page from my own journal — which stands in for a view of a community — gets ljcs-self-tests.js.)

Finally, each fixture page gets a test file based on its layout: the “3 Column” layout gets ljcs-3 Column-tests.js, while “Cuteness Attack” gets ljcs-Cuteness Attack-tests.js. (Hey, I didn’t write or name the layouts; I just have to make sure LJCS works with all of ‘em.) These files will test that the actual DOM manipulations work properly.

Without test-driven development and automated testing to ensure that each layout and page-type is being handled properly, I don’t think this project would be manageable at all.

Do I really want to just write the whole thing, and then start profiling it to see where the hot spots are, and then possibly have to re-design the whole thing? That seems like the complete opposite of “work smarter, not harder”. Then again, it doesn’t matter if you write an O(n²) or even O(n!) algorithm if n is always going to be small… and in this application, I expect low-to-middling n values.

Of course, even if n will always be small, and increasing CPU power is my friend… even if it performs fast enough to make users happy, I’ll still know there’s a problem down there in the details. That may be the deciding factor.