Vincent Gable’s Blog

December 11, 2008

There are Worse Things Than Crashing

Filed under: Design,Programming | , ,
― Vincent Gable on December 11, 2008

Crashing is not the worst thing a program can do. Data-loss and corruption are worse bugs than crashing. I think this is generally accepted in theory, but I often hear developers say things like,

If there’s one behavior of your application that you should focus on eliminating, it’s the behavior of crashing. Above all other “nuisances,” this is the one that is absolutely unacceptable.1


And I certainly agree that crashing is unacceptable, and a high-priority bug. But it’s not the highest priority kind of bug.

For example, say your bank’s website crashes all the time. That sure sucks for everyone! People will be upset, some of them enough to take their business elsewhere. But if the website even occasionally moved the decimal point around when you sent money, the bank would be out of business faster than you could say suedfornegligence.

Even for software that isn’t used by banks, hospitals, nuclear reactors, etc., the basic principle is the same, it’s better to crash than vandalize people’s data.

As with any general rule, there are exceptions. It’s probably worse if an email program crashes than if it “corrupts” data by adding an extra space to the end of of a message. In fact, Mail could be doing this right now, and I wouldn’t know or care. (Outside of movie plot scenarios where evil CS 101 students are holding the city hostage, and I have 10 seconds to defuse the bomb by sending an email with a body containing the de-activation code and not a single extra character. Although to be fair, there’s probably a clause in Mail’s EULA saying it’s a violation of the terms of sale to use it to defuse thermonuclear weapons.)

But the threshold of “acceptable” corruption is vanishingly small. If about 1% of the time Mail made the subject-line of an email all lowercase, that is plausibly worse than a 1% chance of crashing. It’s not OK for the subject of a job-application email to be changed to “vincent gable, professional and detail-oreinted programmer“[sic] (and you know what they say about first impressions).

The Unthinkable

I think a lot of why crashes are thought the worst thing a program can do is, fortunately, crashes are the worst thing most programs will ever do. So they end up taking the #1 spot on the bug severity triage sheet.

Data-vandalization is orders of magnitude less common then crashing in shipping programs. And if you count crashes during development, that proportion shrinks dramatically. Every non-trival program has crashed at some point during the development process.

And a leading cause of data loss is programs crashing without saving something. Do you classify that as a data-loss bug or a crash? Well, the crash is the thing that needs to be fixed to solve the problem, so probably a crash.

Small wonder then that crashes are considered by some to be the worst kind of bug, even though erasing or corrupting someone’s data is worse. Most recently, I have been going by Wil Shipley’s bug triage priorities, which give highest priority to “Data-loss bugs”.


1 I don’t mean to call out Daniel Jalkut; his was just the first quote that jumped to mind. And for all I know he agrees with me, and classifies mauling a user’s data as something worse than a “nuisance”.

November 24, 2008

How To Space Your Code For Maximal Interoperability

Filed under: Design,Programming,Quotes,Usability | , , , , ,
― Vincent Gable on November 24, 2008

The new rule for indentation and alignment: use tabs for achieving an indentation level, spaces for character alignment within an indentation level.

Christopher Bowns (and independently Peter Hosey)

The arguments make total sense to me. Here’s hoping for better IDE support in the future. Unfortunately, (though interestingly), according to Steve Yegge, indentation is very hard:

I would have been publishing this article at least a month ago if it weren’t for indentation. No, six weeks, mininum.

See, I thought that since I had gone to all the thousands of lines of effort to produce a strongly-typed AST (abstract syntax tree) for JavaScript, it should therefore be really easy to do indentation. The AST tells me exactly what the syntax is at any given point in the buffer, so how hard could it be?

It turns out to be, oh, about fifty times harder than incremental parsing. Surprise!

Here’s a forward-looking (somewhat contrary) opinion,

Soft-wrapped code (leaving a long line long, and letting the IDE handle the spacing) also appears to be the direction that Apple are heading and they tend to drag a lot of Mac programmers along in their wake.

Matt Gallagher

I For One Welcome Our Vector Overlords

Filed under: Design,Quotes | , ,
― Vincent Gable on November 24, 2008

The pixel will never go away entirely, but its finite universe of digital watches and winking highway signs is contracting fast. It’s likely that the pixel’s final and most enduring role will be a shabby one, serving as an out-of-touch visual cliché to connote “the digital age”

JH

I’ve written before about trends in resolution independence, and why it matters.

November 3, 2008

Voting Done Right: Wait For It

Filed under: Design,Security,Usability | , , , , , ,
― Vincent Gable on November 3, 2008

Everyone wants to know the results of an election as soon as possible, including me. I will be spending tomorrow evening with friends, watching election results on live TV. I’ll be unhappy if a battle-ground state is slow to report, and I expect to know who the next president will be before I go to bed. But quick reporting of election results is in no way necessary, and in fact undermines our electoral system. We should put trustworthiness ahead of entertainment, and count votes deliberately.

According to the project triangle, you can do something quickly, you can do something cheaply, and you can do something well, but you can only do two out of three.

I propose that official tallies should not be released for 72 hours after polls close, by law. This gives us time to do voting right, and affordably.

A Hard Problem

Engineering a good voting system is a much harder problem then most people realize.

The system must be resistant to fraud by voters, and election officials, and the politicians on the ballot.

Voters must vote only once. But nobody can tie a particular vote to someone (that would allow voter intimidation and buying). But their vote must still be counted for the right candidate.

Tallies must be auditable (in case of a dispute a third party can re-count the votes). The whole system must be perceived as trustworthy and transparent by everyone.

Oh, and it has to scale to use by hundreds of millions of people on election day.

And all of this has to be built, and maintained, with very limited public funds.

This is a very hard problem already. Adding the extra requirement, “and final results must be ready two hours after polls close (so results can make prime-time TV)” would, in my opinion, make it an impossibly hard problem. Unfortunately, that is the direction we are moving.

No Need to Rush

Our electoral system was designed in an era when, cliché as it sounds, the pony express was the fastest way to communicate intra-nationally. Officials do not take office for several weeks after they have been voted-in. Delaying the certification of a successor until Friday would not incapacitate government. It’s always clear who the current officials are until new ones take office.

Of course, today we live in a faster, more connected, world. It could be argued that this means we have a modern need for instant results. Fortunately, this does not appear to be the case. The fallout of the Bush v Gore election in 2000 proved that society and government can function just fine for several weeks without knowing who won an election.

The Fear

Confidence in modern voting machines is rightly low. For the first time in nearly three decades, there will be a decline in the number of people casting their ballots electronically. Nobody (lobbyists aside) seems to really think that these voting machines are a working out for us, except that they do give “tallies” faster.

Personally, I am terrified of an all-electronic election. The reason is simple: it can’t be audited. Digital forensics just aren’t real enough. If someone stuffs a ballot box, they leave a trail of clues, down to the chemical composition of the paper. But there’s no record when bits are flipped to a crooked candidate. Any digital footprint can be faked. “Recounting” an electronic election would be pointless — asking the same program to run the same calculation, with the same data.

Of course, there are exotic solutions. It might be possible to develop a digital storage media that can only be written to once, and would record forensic information, like the time of each write. Unfortunately, none of these ideas sound remotely cost-effective. Which leaves….

Good old physical paper ballots. Slow, but sure, they are a proven technology that has earned our trust.

… then the Opposite of Progress is…

So why not simply mandate that paper ballots must be used for an election? Personally, I think that would give us a better election system then we have today. And it’s probably got a much better chance of happening then my idea of sitting on election results for three days.

But I don’t think it’s the best long-term solution. Historically, laws just don’t keep up with technology. And we have every indication that the pace of technological change is increasing. A little over seventy years ago, the Social Security Number was born. Today, we are stuck with them. I’m not convinced that paper will be the best medium for recording votes in 70 years.

Rather then dictating anachronistic implementations, it seems better to codify the right trade offs to make when designing a voting system. Then we can organically reap the benefits of advances in voting-technology, as we have historically.

The real problem is that we, as a voting public, are favoring quick results over reliable ones. This is a social problem, it is not a technological problem. It is best to directly address the social expectations, not the technological details.

But honestly… it will never happen. We like our prime-time TV and instant gratification too much. Withholding election results, even temporarily, feels too dictatorial. We can expect to get our votes counted faster every year. I just hope it’s not at the expense of counting them correctly.

October 12, 2008

Customers are Not Users

Filed under: Announcement,Design |
― Vincent Gable on October 12, 2008

Customers and users are not the same thing. The distinction is important but often missed.

A user is someone who uses the software you make.

A customer is someone who chooses to give you money for your software.

For many classes of software (eg a POS system), the majority of legitimate software users are not customers. They are using software chosen by someone else, often their employer, or an OEM.

The first step to satisfying both users and customers is to not confuse them.

October 9, 2008

Function Over Brand

Filed under: Design,Quotes | , ,
― Vincent Gable on October 9, 2008

There is something to be said for the fact that the phone with the strongest brand in the world has no visible branding whatsoever on its front face.

John Gruber on the iPhone. But you knew what phone he was talking about.

I’ve always been deeply opposed to any branding strategy that values a brand over a product. Adding branding to something’s “face” makes it harder to use, because it adds visual noise to the very part of the thing you have to interact with (and figure out how to use). For example, an “Intel Inside” sticker next to a keyboard is one more square-thing you have to rule out when looking for the right button to press.

October 8, 2008

Drawing the floor()

Filed under: Bug Bite,Cocoa,Design,MacOSX,Objective-C,Programming | , , , , ,
― Vincent Gable on October 8, 2008

So when drawing a custom-Cocoa-control, I had an issue where an NSImage (bitmap) and an NSBezierPath (vector-shape) didn’t move in sync with each other.

Using floor() to force all pixel-coordinate to be a whole number fixed the problem. There is probably a much better solution — after-all this was the first custom-control I have ever done in Cocoa. But when a simple solution works…

UPDATED: 2009-05-25: @cocoadevcentral tweets,

NSIntegralRect() and CGRectIntegral() take a rect and return a copy which is aligned to integer coordinates. Good to avoid blurriness.

They sound like a better solution then calling floor() on each element of an image.

October 7, 2008

Photoshop Upgrade Refusenik

Filed under: Design,Quotes | , ,
― Vincent Gable on October 7, 2008

I hadn’t heard of Bob Staake before but, according to Wikipedia, he’s kind of a big deal:

Illustrations by Staake appear in The New Yorker, Time, The Washington Post, The Chicago Tribune, The Wall Street Journal, The Los Angeles Times, The New York Times, and others. Illustrations by Staake are used in advertising by such companies as McDonald’s, American Express, Sony, United Airlines, Nickelodeon, Sports Illustrated For Kids, Ralston Purina, Hallmark Cards, Kenner Toys, and others.

Starting in 1993, Staake illustrated and contributed concepts to The Style Invitational, which is a humor contest at The Washington Post.

In 1995, Staake became a regular contributor to Mad Magazine.

In the September 4, 2006 issue of The New Yorker, Staake created the first of many cover illustrations to follow for that magazine.

Interestingly, he still uses Photoshop 3, first released over 12 years ago,

Let me clear up today’s rumor: I do NOT work in OS 7. I use OSX and run classic (9.0) in the background. Photoshop 3.0? Yes, STILL use that.

Responding to some brouhaha over his tools, he made it clear that it’s by choice,

I love how every tech geek out there goes POSTAL over the idea of an artist using software that they’re comfortable with – even if it’s old.

Reminds me of people who still think Microsoft Word 5.1 was the best version ever. Personally, I don’t think they are off by much, although given my spelling, a word processor without spellcheck-as-you-type just won’t cut it.

October 5, 2008

Unfaithful Design Gives People Salmonella

Filed under: Design,Security | , ,
― Vincent Gable on October 5, 2008

This New York Times article explains how dozens of people in several states contracted salmonella after they mistakenly microwaved raw chicken, instead of throughly cooking it in an oven.

According to the Department of Agriculture, the dishes included breaded or pre-browned chicken breasts, some of them stuffed with vegetables or sold as “chicken Kiev” and “chicken cordon bleu.” The appearance of the food led people to assume that the chicken breasts were thoroughly cooked, even though they were still raw or undercooked inside.

According to the USDA alert (emphasis mine)

Although many of these stuffed chicken entrees were labeled with instructions identifying the product was uncooked and did not include microwave instruction for preparation, individuals who became ill did not follow the cooking instructions and reportedly used a microwave to prepare the product.

This is what I would call a failure of labeling. Showing a fully-cooked chicken cordon bleu is clearly more appetizing then a picture of raw meat; but it is not a totally accurate depiction of what’s in the box. I wouldn’t call it unethical in and of itself, but the embellishment should have been offset with a clear indication that the meat was raw. Especially since it’s impossible to tell if a frozen piece of fully-breaded chicken is raw or cooked. If the USDA alert is taken at face value, then only “many”, not all, of the frozen chicken was labeled as raw. That does not seem right.

Unfortunately, no brands were named in the alert. So I can’t comment on the actual designs.

October 3, 2008

Release When Ready

Filed under: Design,Programming,Usability | ,
― Vincent Gable on October 3, 2008

There are lots of people who strongly suggest that you should do your development in public. It is part of the “release early and often” concept. But I also believe that this concept is not effective in developing great ideas because it is limiting. The minute that you get real customers involved, their needs become much more pedestrian. They will yell loudly about things that may be important to their use of the product, but they will rarely yell about some new game-changing concept. In fact they will resist radical change and rethinking because it messes with their now committed workflow. And now you are comitted to supporting them. So as I see it you should strongly consider whether you have enough meat on your conceptual bone before you decide to release publicly. Because when you get users involved, it is the equivalent of putting the saw and the screwdriver down and grabbing the sand paper. There will likely be few additional big ideas after that point.

Hank Williams

« Newer PostsOlder Posts »

Powered by WordPress