An Analogy

Risk is something that you either purposefully manage or you roll the dice with your life, sometimes literally. I ride/race a motorcycle as my main hobby away from the computer. Riding a moto is a risky activity and I do several things to manage that risk:

• Always wear a helmet, gloves and jacket
• Ride a relatively low power bike
• Taken every MSF training course available
• Refuse to ride in groups

Do these guarantee I won’t crash? Certainly not but I hope they will lessen the odds and minimize any damage if I do.

Managing Risks

As engineers, what are the risks of working at a startup? The main risk is the company failing and going bankrupt. A second, related risk is being laid off. In both cases, your job and paycheck are at risk. How do we manage those risks? I have three tactics to manage the risk of working at a startup.

1) Make it as easy as possible to find a job

You could make yourself essential to the operation of the company; that helps with layoffs but does not help with bankruptcy and has the drawback that you will start from square one at the next startup. My strategy has been to make myself a valuable developer, independent of any one startup, by working on open source software and maintaining a high quality blog that evangelizes myself and my work. This is a last resort strategy: if anything happens to make my job disappear, ideally I can interview and find another job within days. This recently proved successful when I announced my upcoming move to San Francisco and had 20-30 inquiries over the next few days.

2) Exercise common sense and your math skills

Do you know your startup’s monthly burn rate, cash reserves and revenue? I’d bet that the majority of people at startups do not. Get those numbers and figure out how many months the company has before it has no money. Just a few months left? Would it be difficult to raise more money? Are you part of a “layer of fat” that could be laid off to cut the burn rate? Is revenue rising or dropping? Are you getting more customers? These are questions you should be asking yourself every month to evaluate the health of your startup. At some point you will need to leave on your own terms, before you are forced out by bankruptcy or layoffs. I left FiveRuns last year when these questions made bankruptcy look unavoidable. Leaving on my own terms meant I could take a few weeks to interview around to find the right job.

3) Stick with Success

They say failure is the best way to learn but in my experience nothing breeds success more than previous success. I try to stick with entrepreneurs that have past successes. As developers, we want to work with smart developers, yes, but you also want to work with great business guys who have a network of contacts, know how to raise funding and can navigate the company to a successful exit. I can interview a person to learn if they are a good developer but I can’t interview a CEO to learn if they are a good CEO. I have only two metrics:

• do they have a reasonable business plan with a way to make money?
• have they had previous startup successes?

The “halo” effect is very real. VCs are more willing to talk to someone who has previous success and knows the funding process. People are more willing to work at a company run by someone with previous success. Press is easier to get and customers are easier to talk to if they already know the company as the latest effort by a successful entrepreneur.

4) Educate yo’self (Extra bonus tip!)

You may know computer science but how much do you know about management or finance? Read a management book. I recommend anything by Peter Drucker – he literally invented the science of management and his writing really opened my eyes. Read a book on business finance. You’re not trying to become an expert in these fields but when you learn a little bit about the other major roles in a startup, you’ll be able to evaluate your startup’s current situation more accurately.

Even with all this, you will fail often. I’ve been part of two moderately successful exits and several bankruptcies. I’ve only been caught flat-footed once and tried to learn as much as I could from that experience. No matter what happens the startup experience is rewarding but with a little foresight you can minimize the inevitable risk to yourself and your livelihood.

1) Request an invite by signing up at https://dash.fiveruns.com
2) Log into Dash, create a new Rails application and note your application token.
3) Install the gem:

sudo gem install json
sudo gem install fiveruns-dash-rails -s http://gems.github.com

4) Add the gem to your config/environment.rb

Rails::Initializer.run do |config|
  config.gem 'json' # needed because of a bug in json_pure
  config.gem 'fiveruns-dash-rails',
             :lib => 'fiveruns_dash_rails',
             :source => 'http://gems.github.com'

5) Add the initializer file config/initializers/dash.rb to start Dash:

if defined?(Fiveruns::Dash)
  Fiveruns::Dash::Rails.start(:production => 'YOUR-APP-TOKEN-HERE')
end

This will start Dash in the production environment. We don’t recommend using Dash in development mode. If you have a staging environment, you can create a separate app for that environment and combine the two like so:

if defined?(Fiveruns::Dash)
  Fiveruns::Dash::Rails.start(:production => 'PROD-TOKEN', :staging => 'STAGE-TOKEN')
end

Email me if you have problems – I’m happy to help people give Dash a test drive. Dash is 100% free right now until we’ve worked out pricing models but rest assured there will always be a free tier so you don’t have to worry about your app costing you money in the future. I hope your Dash test drive is full of rimshots with no sad trombones!

• An application which makes farting sounds was selling 40,000 units/day.
• I’ve had a secret dream for a year…

My dream? To make a $5 keychain sold at the checkout stand in Wal-Mart which just plays gag sound effects. The keychain’s user interface is dead simple: three buttons, each of which plays a sound. It may sound ridiculous but I do this all the time in real life. I tell a joke and make a rimshot noise. Or I tell a joke, it bombs and I make the sound of crickets. A keychain is something you always have in your pocket, ready at a moment’s notice (at least the fellas do, sorry ladies!).

The hard part about this is finding someone to design, build and stock a keychain in tens of thousands of units. The investment needed could easily go into tens of thousands of dollars. What I realized is that cell phones are just as easily accessible and the iPhone makes this possible to do all in software. It’s not quite the perfect solution but the advantages for me far outweigh the drawbacks.

Thus, I built Zinger, my own take on the perfect comedy assistant. The UI is as fast and simple as possible. You touch the icon, it presents you with three big buttons; you really cannot get any simpler. And simplicity is what you are buying here: the more buttons you have to push to get to the sound effect, the less useful the app is in general, and when you are looking for a zany sound effect, timing is everything.

It may not outsell iFart but I hope it makes people laugh just as much. Enjoy!

Here’s my RubyConf slides (1MB, Keynote), minus the screencasts I created to demo the two worker modules in action.

There are two modules provided:

• TokenWorker ensures that one process from a group of redundant processes will be elected to perform processing for the next N seconds.
• StaticQueueWorker distributes a predefined set of work to a dynamic set of processes every N seconds.

Both depend on the standard Ruby library and memcached. StaticQueueWorker also depends on net-mdns for Bonjour functionality.

You can find the code on github with a more detailed overview and examples of how to use the modules in your own code. If you find the software useful, please consider recommending me at Working On Rails.

In other news, this week marks my first anniversery in the professional Ruby world.  I’m pretty happy with what I’ve achieved so far and I hope the next year is just as fun and challenging.

1. “yum update” to get the latest security and OS updates
2. Install REE.
3. Install Passenger.
4. Configure apache to use REE and Passenger.
5. Deploy my latest tracknowledge source running on Edge Rails (i.e. 2.2 alpha).

You might wonder why I’m running Edge Rails.  Well, I wanted to get the multithreading and connection pooling features in ASAP so I can test them.  DataFabric does rely on some of the innards of ActiveRecord’s ConnectionAdapter class so I’ll probably need to make changes to get it working on ActiveRecord 2.2.

<an hour passes>

And it’s done!  Wow, that was pretty easy.  The hardest part by far was simply updating my app to list its gem dependencies and install those gems in the new gem repo for REE.  Kudos to the Phusion guys for making Rails deployment MUCH MUCH simpler!

How NOT to Build a Service (Keynote, 2.5MB)

How NOT to Build a Service (PDF, 2.2MB)