As Kickstarter gets more popular, I’m seeing more lousy Kickstarters. Most of them get ruined because they break the fundamental rules implied by any Kickstarter project:

1. If you don’t meet the backing goal, this project will not happen.
2. If you do meet the backing goal, this project will happen.

In case they’re not obvious enough, an example:

The Furry Pink Car Example

Let’s say I built an absurdist art car, and I want to add furry pink seats in time for the next Burning Man. I have a good reason to want the new seats: riding in the car without them is uncomfortable enough that people complain loudly. However, I don’t have the funds to add them myself.

I have some rewards in mind: an exclusive video of the seats being installed, a ride in the car itself, and for top backers, your name painted on the passenger door.

I know there are plenty of people who would back my project, so I’m ready to go. How could I screw it up?

Remember: If the goal isn’t met, the project won’t happen.

Easy. I could state my project in broader terms than I’m actually funding. “Absurdist Art Car at Burning Man 2013!” My project video could talk all about the car, with a quick mention of how pink fluffy seats would be nice.

When potential backers read that title and watch that video, they’re left with a big question: “You already have this car. Why do you need more money?” From the project page (which is all they have to go on!) it sounds like the project will happen whether they back it or not.

I had this feeling about a recent space company that went the crowdfunding route. The rewards were the usual space-company merchandise, and the project boiled down to “Help us do what we’re already doing!” My contribution wasn’t going to make a difference, so I didn’t bother.

How could I fix it? Change my title to “Pink Fuzzy Seats: The Only Way To Travel” and describe the benefits (and unreasonable expense!) of the all-important seats. If the money doesn’t come through, the art car will be as uncomfortable as it was last year, so no rides for anyone!

Great! How could I screw that up, then?

Remember: If the goal is met, this project will happen.

Messing this up is more subtle, but a lot more common. There’s an assumption underlying my whole project, something I might completely miss by (correctly) stating the goal narrowly. Take a look: can you spot it?

That’s right: I need a working, drivable art car. The rewards require it, the seats are useless without it. If something happens to that car so that I can’t take it to Burning Man, then I’m on the hook to fix it.

WITHOUT asking for more money. That’s the really tough part. Going back to those fluffy-seat backers with a second Kickstarter (or IndieGoGo, or anything like it) seems natural, but it’s dead wrong. By asking for new funds to make an old project possible, I’m casting doubt on my ability to complete that project at all. Why would my backers throw good money after bad?

I often see this problem with films and other art projects, the kind that have lots of steps. (Writing, shooting, editing, post-production, distribution, aigh!) It’s natural to make the film the project, with backer rewards to match, but if you’re just funding the first steps you should only provide rewards from those steps. (A rough cut of the film, for example.) Don’t offer the whole film if you’re only funding part of it.

In my case, I’m resolving to keep the car running and get it to Burning Man, no matter what. It’s something I would have had to do anyway, but now my backers are relying on me to get the furry pink seats on the road.

Note that I’m not going to list “car breaking down” as one of the “risks” or “uncertainties” on the project page, either. If Burning Man is canceled, that’s an uncertainty. If faux pink fur melts in the Black Rock sun, that’s a risk. However, I’m pledging to do everything I can to get the car there, and it’s reasonable to expect me to deliver on that promise.

It may surprise you to discover I still work with Facebook on a daily basis. I did leave Facebook as a user over three years ago, but wrangling the Graph API is still a core part of my job. (For the web developers among you: It’s like your relationship with Internet Explorer.)

Last week I was updating Measured Voice to match changes in the Facebook permissions dialog, and I noticed that the documentation said one of my permissions was now out of date:

“Facebook used to have a permission called publish_stream, publish_actions replaces it.”

– from the Facebook API’s Extended Permissions documentation

In a fit of eagerness, I broke the first rule of API usage* and switched out publish_stream for publish_actions. However, it soon became obvious that the two weren’t equal. The auth tokens produced before and after my update were markedly different:

with publish_stream

with publish_actions

Requesting publish_stream gave me publish_actions anyway, which makes sense if the two are being treated as equals, but it also gave me a whole passel of other permissions I hadn’t asked for. As it turns out, at least one of those permissions is still necessary to do what I need: post status updates and photos to a Facebook Page.

But which one? I checked the documentation again, and… well, none of them are documented at all. Not listed anywhere, not mentioned as deprecated, not anything. Huh. Some of them do sound like permissions I’d need (photo_upload and status_update, for example), but without documentation it’s just a guess.

It sounds like the documentation is ahead of the actual API development, and reflects some design goal instead. Or maybe this is (yet another) API bug. Either way, I’m going back to requesting publish_stream until they get their facts straight. It still works. (For now.)

* “If it ain’t broke, don’t upgrade to the new revision.”

Passwords bug me. Specifically, password management on most websites is maddening. Here are a few things to keep in mind when designing yours:

List your password-format rules up front. All too often, sites ask for a password with no indication of their format rules, then scream “ERROR!” when you don’t guess correctly. Yell at your users less by telling them what you want first.

Don’t limit the size of a password unless you absolutely have to. Honestly, it’s 2012. Databases can store unlimited-length strings, and the security of a password is improved by length. If your user wants to use the Gettysburg Address as a password, let them go for it.

Ditto for the content. If the user wants ancient Greek poetry for their password, then don’t freak out about the character set or complain that it doesn’t contain any numbers. Honestly, I once had a health-care provider prevent me from using spaces and punctuation in a password. “Alphanumeric characters only”. Way to be secure, guys.

Don’t limit the password format at all unless a compromised account will damage your service as a whole. No minimum length, no “special characters” requirement, no “at least one number”. I know, this is a tough one to swallow. Take an honest look at the worst a malicious user could do; if the only harmful effects are to the user choosing the password, then let them choose whatever they want.

Rate the strength of a password as the user types, and give hints on how to improve it. If you do this, though, get it right. It’s annoying to type in “correct horse battery staple” and have some out-of-date algorithm tell me it’s “Weak“. It’s worse if the system rejects it outright, but even the knowledge that your algorithm sucks makes me doubt the overall security of your system.

Check that your login fields are friendly to automatic login. I’m more likely to choose a unique password for a site when I can hand off the job of remembering it to my browser or keychain. Each time I have to click “forgot password”, though, my choice is going to be easier to remember (and probably less secure).

Yesterday I did something dumb, and I only realized it today because I don’t trust an easy success. Let’s see if you can spot the flaw in my reasoning:

Background:

• A process (X) is run on a series of items in a queue.
• Items are added to the queue continuously, about 500 per hour.
• A processor (Z) is started once an hour. It performs X on all the items in the queue, then quits once the queue is empty.
• If there are any errors, the processor emails them to me after it quits.

The problem:

1. I noticed 100 random failures in process X each hour.
2. I hypothesized that X is failing due to intermittent system unavailability.
3. I checked the hypothesis by looking for clusters of X failures at times of high load. (There were.)
4. I “fixed” it by pausing the Z processor for 60 seconds whenever there’s a failure (to let system resources recover).
5. 12 hours after the fix, I got no failure emails and declared victory.
6. Not so fast: Not only did I not fix the problem, I caused something worse.

Can you figure out what I did wrong? Continue reading →