think pink

a weblog by  Elliott Kember

I’ve recently been playing around with monetizing one of my applications: Filetweet. It’s a fairly simple application, designed to allow you to send files over Twitter. You may have seen it; some of you may have even used it.

It’s the first application I’ve built that I’ve tried to charge for – as an experiment. Using the excellent Spreedly service, and the not-quite-so-excellent PayPal merchant gateway service, it’s really easy to start taking money on a monthly basis. The only problem is, nobody is paying. I don’t think anybody will ever pay. It’s just not that viable a system for people to spend £5 / month on. There are probably even other services that fill the same gap.

But you know what? That’s okay. I don’t really mind if I don’t make any money on Filetweet. It’s supposed to be an experiment, which means that it will most probably fail.

One problem with this ultimatum is that I’ve used the wrong terminology. To “fail” is generally to experience no growth – failing to establish a user base, generating no profit, and not really fixing a problem are good general indicators of failure, and reasonably apt descriptions of Filetweet.

However, I think this terminology is wrong. It’s very depressing to fail, even when you’re expecting it. Every application I build, I secretly hope that it will be the next Basecamp. Can this repeated “failure” be any good for morale? I don’t think so – and I think my own point of view is to blame.

Perhaps on paper the project is a loss – but intangibly it’s a victory. It’s like, the opposite of a Pyrrhic victory, if there’s a name for that. The problem is, everybody tries to get things right the first time. There’s no margin for error. Every time you do something new, you’re trying to do it right – which is absurd.

As developers, in code, we prototype all the time: create a small, off-master experiment branch and try something out. Sometimes it works, but very often it doesn’t, and usually it’s never folded into the main branch, at least without some refactoring.

Why is it, then, that we place so much stigma on “failure” and “success” with individual business ventures, when so little is placed on the success or failure of individual parts of our code? I think the only way to fail from a project is to come away with nothing. If you learn anything, improve at anything, or streamline your development process, you’ve achieved something.

%h3 The Juice and the Squeeze

If the project were to succeed, would the payoff be worth the cost of failure? In ruby:

  def valid?
    return (failure.cost * failure.probability) > (reward - costs)
  end
  

Of course, it’s not that simple. Knowing the true cost of failure, and the true probability of failure, is a very difficult art. There are, however, several things you can take into consideration:

• Amount of maintenance required
• Any ongoing costs (hosting)
• Possibility of future feature requirements
• Complexity of the application

- all of which will add to the cost of either success or failure.

In Filetweet’s case, the answers are easy: not much maintenance, S3 means very little ongoing cost, feature requests are unlikely, and the application is not very complex at all. In actual fact, if this rings true – if the hard work involved is not very high, you might just be wasting your time trying to achieve success. Why?

Risk == reward

This is where it gets difficult. The more you put into something, and the more you stand to lose, the more you generally stand to gain. Conversely, it’s harder to risk nothing and hope to achieve everything.

But we’ve strayed from the original point of this article – the flawed concept of success. If we’re redefining success, we have to look at that formula again.

  def valid?
    failure = (failure.cost * failure.probability) 
    tangible_success = reward.tangibles - costs.tangibles
    intangible_success = reward.intangibles - costs.intangibles
    success = reward.intangibles + reward.tangibles - costs.tangibles - costs.intangibles
    return success > failure
  end
  

Even harder – since the intangible rewards are completely subjective. Intangible costs are generally your time, your sanity, and your hard work. The only way to really make this equation easier for ourselves is to do one of two things:

• Reduce the probability of failure, or
• Reduce the cost of failure, or
• Reduce the amount of time and effort you expend

Or,

• Don’t fail, or
• Fail cheaply, or
• Fail quickly

Fail cheaply and quickly

This point is the crux of this article. With today’s range of scalable hosting services – like EC2, and Heroku – and the number of VPS providers around – VPS.NET, Linode – you can really afford to fail cheaply. “Failure” in the commercial sense is immensely valuable – as far as I’m concerned, it’s the real shortcut to success. Any developer will tell you that learning from your mistakes is immensely valuable.

After I finished writing this article, I came across this, entitled “You will fail”. It’s a great article, and I think it expresses what I want to say. I guess what I’m doing is just pre-empting the inevitable.

Prototype rapidly, and fail cheaply and quickly, so when you’re ready to risk everything, you know what not to do.

If you have a good story about any of the failures you’ve been a part of, I’d love to read about them in the comments. You’ll have to log in with Twitter.