kai_mactane: (Default)

When a company says “we can’t afford a QA department”, what they’re really saying is, “we accept that our software will be infested with bugs, and quality is not important to us.” When they compound this basic error by saying, “the developers will just have to do their own QA”, they prove that they have no respect for developers or QA people, and you shouldn’t work for such a company in either capacity.

(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.

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

The more stuff you have open (or habitually leave open) in an application, the more it becomes part of your consciousness, an extension of your mind. For many of us, the question “What are you doing right now?” could best be answered by, “Here’s a list of the tabs I have open in my web browser.”

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.

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

When should you ask a user “Are you sure you want to do that?” Bear in mind that asking this question when you don’t have to has more than one bad effect:

  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”.

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

A good domain name should have the following features:

  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: 10100, 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.

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

Recently, a bunch of the blogs and journals I read (including my friends, not just big, famous sources) have had some bones to pick with Clifford Stoll’s 1995 Newsweek opinion piece, “Why Web Won’t Be Nirvana”. Stoll said: “no online database will replace your daily newspaper, no CD-ROM can take the place of a competent teacher and no computer network will change the way government works.”

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?

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

If you’re going to reinvent the wheel, you should at least make sure your new version is somehow better than the previous kind. Reimplementing standard UI and OS widgets is one of the most common ways developers reinvent the wheel these days — it started with Flash developers building their own controls, and has now spread to Adobe AIR and Silverlight.

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?




Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

Let’s say one day you decide to add a feature to your software or service. For example, you need a new flag on user accounts, so that different types of users get different features. (These don’t even have to be tiered account levels; maybe accounts of type “music lover” get a widget in the sidebar with suggestions for bands they might like while “sports fan” accounts get a sports scores widget instead.)

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

Read the rest of this entry »

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

My latest project is something I call “LJ Content Sieve”: a Greasemonkey script to filter out content on one’s Livejournal views based on nearly any attribute of a post or comment.

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.

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

I don’t want to optimize this code prematurely. And “while you’re still writing it” is probably premature. On the other hand, totally ignoring algorithmic complexity is a sure route to a Shlemiel the Painter’s algorithm.

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(n2) 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.

Originally published at Coyote Tracks. You can comment here or there.

Profile

kai_mactane: (Default)
kai_mactane

July 2011

S M T W T F S
     12
3456789
101112 13141516
17181920212223
24252627282930
31      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 21st, 2017 06:37 am
Powered by Dreamwidth Studios