Anyone who knows me knows that I am a poker player, both at the table, and in life. There's a lot of things I learned while honing my skills that apply to the startup world. My initial venture into playing poker "for real", with buyin stakes of more than 5 or 10 bucks, was in college. I was recruited to be the new fish in the Champaign-Urbana elite poker club. There was no formal declaration of such, but it comprised of mostly PhD grad students in Math, Physics, and Computer Science. I was the only undergrad to regularly play. After separating me from my "tuition", they agreed to teach me their secrets. This was back before you could simply Google millions of pages to find endless poker advice. Instead, I was directed to some books. I read Lee Jones "Winning Low Limit Hold'em", Sklansky and Malmuth, and watched videos of Mike Caro explaining how to spot tells. In some ways, the education I got from this group of friends was more valuable than many of the classes I took as a Physics undergrad.
The basic skills of poker are still important, but tournament poker requires you to take it to another level. It's harder to win, but the payoffs are huge when you do hit. The key difference between a regular poker game and a tournament is that you start with an equal amount of chips. If you lose them, you are out of the tournament and may not buy back in. Some tournaments do allow you to rebuy and/or add-on, as anybody has seen me do numerous times at Poker 2.0, but sooner or later, it either doesn't make sense or is no longer available.
At a startup, your initial buy-in represents an amount of time that you can operate. This is known as your Runway, with time measured in months at this stage. In poker tournaments, it's useful to also measure your stack in terms of how many times you can survive the blinds. That gives you a sense of how long you can wait for a premium hand, or if you need to seize the moment and take a chance. The interesting thing with startups, though, is that you have some control over what the blinds will be, based on how many people you hire or where you choose to locate your office. In poker, you don't really have these choices. The blinds continue to go up until it's over.
Poker tournament buy-ins range from $10, for fun social games, and can be as large as $10-50k for the biggest pro tournaments like the World Series of Poker. Most players can't afford to enter into these larger buy-in games, but if a player can prove their skill, and is lucky enough to know the right people, he can get staked to play in the big games. This is basically the same as a startup raising money. As an entrepreneur, you have to evaluate opportunities based on their potential size and your ability to act on them, but you still need to know the right people to make it happen. Are you going to work at night on a hobby app that might make a couple hundred bucks, or do you want to get into the big game and make millions?
Some players opt to enter into satellites to win their buy-in at the bigger game. For $200, you can enter a tournament that awards the winners $10,000 seats in the World Series. Satellites in the startup world come in the form of pitch competitions, where you battle against a number of other startups in hopes to get a buy-in to the big game.
At the end of a lot of tournaments, the pot may get split between a few remaining players in a deal. You negotiate your equity in the pot and take your cuts. Sounds like a liquidation event if I ever heard of one. We all hope to make the final table, both in poker tournaments and in startups. Do you have the skills to get there and win?
See also: Entrepreneurship and Poker
Android Ate My SD Card
Every android device depends on having an SD card if you want to take pictures, listen to music, and use a variety of apps and games. Those pictures, videos, songs, and games are getting bigger with each new generation of phones. This is why you will always need to pay a premium for data storage when you get a new phone, because you'll need that seemingly incomprehensible amount. Still, it's usually just 2 or 4 times as much as you already have. That's a reasonable bump up, right? Well sure it is, because there seems to be no end to the constant doubling of sizes and speeds in computing.
After about 7-8 months, my phone's 8GB SD card was full. I take my fair share of photos and video, and I have a lot of albums downloaded on it. What started popping up as more of a red flag was that every time I deleted a few albums or some of the videos of dead air, I noticed that my storage would again fill up rapidly. I have Adao File Manager for Android to be able to see what's taking up some space, but it's not very good at rolling up the stats. Finally, I connected my phone to my computer, since it's easier to clear out the junk and get better stats on folders and numbers of files, etc. While looking around the folders, I see that Music eats up about 1.3-1.5GB, and my DCIM (the real photo directory) takes up about 1.2-1.3GB. That doesn't even add up to 3GB, let alone the other 5. I started opening up every folder and I came across 2 that were substantially eating up space. The first was my bugreports folder. It had a couple hundred of reports for 30-50MB each. The other was for an app, which I won't name here, that had over 11,000 files and was using over 1GB. It took Windows 30 minutes just to delete the files.
The lesson here is that you should watch that bugreports folder. There may not even be a way to turn off bug reporting in your settings. The following post talks about the bugreports folder in more detail. As far as I can tell, they don't have a solution other than to periodically delete the files.
http://forum.xda-developers.com/showthread.php?t=937608
As for the app that is not named, shame on them. There are other apps in that folder with empty caches. They take up 0 bytes. The fact is, the developers probably don't know about this bug, so I might send them a friendly email to clue them in. At iHear Network, we are very conscientious about how much storage we take up, and use only the minimum amount needed to function.
After about 7-8 months, my phone's 8GB SD card was full. I take my fair share of photos and video, and I have a lot of albums downloaded on it. What started popping up as more of a red flag was that every time I deleted a few albums or some of the videos of dead air, I noticed that my storage would again fill up rapidly. I have Adao File Manager for Android to be able to see what's taking up some space, but it's not very good at rolling up the stats. Finally, I connected my phone to my computer, since it's easier to clear out the junk and get better stats on folders and numbers of files, etc. While looking around the folders, I see that Music eats up about 1.3-1.5GB, and my DCIM (the real photo directory) takes up about 1.2-1.3GB. That doesn't even add up to 3GB, let alone the other 5. I started opening up every folder and I came across 2 that were substantially eating up space. The first was my bugreports folder. It had a couple hundred of reports for 30-50MB each. The other was for an app, which I won't name here, that had over 11,000 files and was using over 1GB. It took Windows 30 minutes just to delete the files.
The lesson here is that you should watch that bugreports folder. There may not even be a way to turn off bug reporting in your settings. The following post talks about the bugreports folder in more detail. As far as I can tell, they don't have a solution other than to periodically delete the files.
http://forum.xda-developers.com/showthread.php?t=937608
As for the app that is not named, shame on them. There are other apps in that folder with empty caches. They take up 0 bytes. The fact is, the developers probably don't know about this bug, so I might send them a friendly email to clue them in. At iHear Network, we are very conscientious about how much storage we take up, and use only the minimum amount needed to function.
New Featuritis
Developing for mobile apps has exposed me to a new kind of sickness. Because of how many things are possible on a phone, it's possible to create apps that can do just about anything, and it's very easy to slip into what I call "New Featuritis". It starts innocently enough. You add some flashy animation and it gives the app a whole new life. You connect with Facebook and the app magically fills up with your friends. You add a map and you suddenly have a whole new screen to mess with. Suddenly you feel like the app is finally "good", that the new feature "makes" the app. This excitement tends to last up to a week or more, depending on how fancy the feature is. Then the withdrawal kicks in. Like a junkie whose dope has run out, you feel drained and depressed, desperately trying to score your next fix. And at the end of the day, it was just a feature, and it likely did little to nothing for whether your app is actually valuable to your users.
It's pretty easy to get into the New Featuritis loop. As the maker of software, you can't help but see everything that is wrong with the app and believe that it's just not good enough. In some cases, you have already launched the app and it isn't getting the acclaim you hoped for. The temptation to start adding features is unbearable, and unless you give in to it, you are liable to slip into deep dev depression. But you need to fight the urge to just add new features. It's true what they say, a pig in lipstick is still just a pig, and that's the nice way to put it. There may come a time when you need to take a deep look at your app and decide if it's just a pig.
Still, I would be very careful about how quickly you throw your app in the pig pen and move on. It takes a long time to make a good app, and some of the features you add might not make sense. I've generally been reluctant to remove any features from an app for fear of pissing off the users who have gotten used to them, but this happens all the time. Facebook has changed so many times in their lifetime that the app is barely recognizable compared to the original, and Windows has made many a user extremely unhappy when they buried a feature or program that was a mainstay on one version. People complained so much that they often have to offer a "classic" mode. Were the developers at Microsoft suffering from serious bouts of New Featuritis? Maybe they should have scrapped the whole thing and moved focus to their other products.
And remember, even if you start to get tired of something you built, but have not yet launched, other people haven't yet seen all the cool stuff you have already added. That's generally why it's recommended to launch fairly early to test the viability of your product before you feature it up.
I'd love to hear suggestions on how to fight New Featuritis, if anybody has ideas. Feel free to drop a comment below.
It's pretty easy to get into the New Featuritis loop. As the maker of software, you can't help but see everything that is wrong with the app and believe that it's just not good enough. In some cases, you have already launched the app and it isn't getting the acclaim you hoped for. The temptation to start adding features is unbearable, and unless you give in to it, you are liable to slip into deep dev depression. But you need to fight the urge to just add new features. It's true what they say, a pig in lipstick is still just a pig, and that's the nice way to put it. There may come a time when you need to take a deep look at your app and decide if it's just a pig.
Still, I would be very careful about how quickly you throw your app in the pig pen and move on. It takes a long time to make a good app, and some of the features you add might not make sense. I've generally been reluctant to remove any features from an app for fear of pissing off the users who have gotten used to them, but this happens all the time. Facebook has changed so many times in their lifetime that the app is barely recognizable compared to the original, and Windows has made many a user extremely unhappy when they buried a feature or program that was a mainstay on one version. People complained so much that they often have to offer a "classic" mode. Were the developers at Microsoft suffering from serious bouts of New Featuritis? Maybe they should have scrapped the whole thing and moved focus to their other products.
And remember, even if you start to get tired of something you built, but have not yet launched, other people haven't yet seen all the cool stuff you have already added. That's generally why it's recommended to launch fairly early to test the viability of your product before you feature it up.
I'd love to hear suggestions on how to fight New Featuritis, if anybody has ideas. Feel free to drop a comment below.
Timing is (almost) Everything
You've heard it before, "Timing is Everything". This applies to a lot of things in life, and games in particular. Chess is a great example where timing can easily mean the difference between winning and losing. You need to look many moves ahead to determine what move to make now, and the same can certainly be said of start-ups. It's easy to call the market in the rear view mirror, and I feel like I've been able to call things just before they happen. I just need to figure out how to see more moves ahead and be the one who gets there first, without jumping so far ahead that nobody "gets it". Here's an example that just happened.
While I was walking home from work the other day, I was passing by a Lake Union cruise company and thought, "Someday I might like to take a cruise with them, but I might want to wait for a Groupon." Logically, I figured I could build an app that would pull the Groupon deals via their api, and if a match came up for the lake cruise, it would email me. Taking it a step further, if enough people also wanted a deal for the cruise, we could call the company up and try to convince them to do it. We would have a more compelling sell than a cold call from Groupon, since there would already be demand for the deal.
I was almost giddy with the idea. This was a truly new way to look at the deal space, and surely I could build something that Groupon would have to buy, for fear that LivingSocial, Amazon or Google would buy it first. Then reality set in while I discussed the idea with Matthew Markus. If you ever want to know why something won't work, talk to Matthew. Primarily, the reasons are as follows:
- There's no instant gratification. You can request a deal that may take a long time to happen, if it happens at all.
- There's too many places. It might be difficult to ever reach any kind of critical mass for a place to do a deal, as there would likely be a lot of single requests across the map.
- There's not much incentive for the place to run the deal. Our belief is that only places that are already popular would get requests and they have no reason to run the deal. Places that need customers are the ones that need to run deals, and they are places that either people don't know about yet, or don't like.
Then today, after just a few days of thinking about this idea, Loopt announces the very service that I envisioned.
Of course, it was just as quickly dissed for all the above reasons on Hacker News.
How was it that I had this idea just days before it was announced? Was it really that obvious? Should I have seen it months ago?
Another example was a photo app that you use to take pictures of food to determine and track your calories. Combined with GPS and some fancy image recognition (or just mechanical turk), you could probably get a pretty accurate value over time. Then, a day after "coming up" with the idea, there's a story on Mashable about the same thing.
Back in the day, I was one of the first people to use bookmarklets. At the time, I thought I had invented the idea. Then I had ways to expand the dynamically imported javascript beyond the limits imposed by maximum URL lengths. I basically could have built del.ico.us myself, years before they launched. But in that case, I was probably too early to the game and coincidentally tied up in another start-up.
Fast forward to the present. We released iHear Network on February 1st, 2011. It was truly a one of a kind app and is still, to my knowledge, the only app that mashes up maps + twitter + text-to-speech. There have been some other map based twitter apps, but ours was also the first to present things more as a linear stream, playing forward, than a map/list combo like http://metaki.com/. Below is an article that was posted today, almost 5 months after our launch, about yet another slew of apps, but primarily the new release Banjo.
There has certainly been a lot of hype around location 2.0, the logical extensions of Foursquare and other basic check-in services. In particular, the concept of disposable or elastic social networks around the places you frequent has become a hot topic. I wonder, though, if these concepts are not quite ready for acceptance or if they are valuable at all. While iHear Network has decent traction for an app that has flown mostly under the radar, some people question whether they really want to hear all the random thoughts of people they have no actual interest in. Do I care what some dude in New York is saying, especially if his location just happened to be turned on? We've seen a majority of tweets that have location by accident more than by purpose. It's not convenient for a user to manually toggle location on just for the tweets that have something to do with location, and then toggle it back off for a random comment about some TV show they are watching. Most people probably forget they even have it turned on (and this is probably a bigger problem than most people realize for privacy and safety reasons).
At iHear, we are working on these problems in location and relevance, and it seems very clear that whoever solves them will do very well in the end. Did I finally get the timing right this time? I guess we'll see.
AndroidTips: Using Logcat to Maximize Debugging
Building complex systems has forced me to think about what my code is doing at large. Often there are multiple threads of execution happening at the same time. Whether that comes in the form of a web service, where there are many clients accessing shared resources, or if it is an Android app, with worker threads feeding the UI thread, having good logging can make a big difference when it comes to tracking down problems and really seeing what your code is doing. In situations like these, it is very difficult to just use a normal debugger, because it is dependent on all the threads working together. Here's a couple tips and tricks for what I like to do with logcat on Android.
Assumption: You know what a terminal shell is (linux/mac) or a command prompt (windows). I recommend using http://www.cygwin.com/ for windows, but I'm a linux geek. You should still be able to do much of what I'm talking about with a normal windows command prompt.
Tagging: Make sure that you use sensible tagging on your calls to Log.d(). A reasonable policy might be to use the fully qualified class name. I usually chose something smaller than a full package prefix, but something that should be pretty unique to my code. Also, you should be sure to use a static constant to define your TAG class by class. Here's a code snippet example of what I'm talking about.
private static final String TAG = "MyProjectActivity";
....
Log.d(TAG, "Beginning process X");
Assumption: You know what a terminal shell is (linux/mac) or a command prompt (windows). I recommend using http://www.cygwin.com/ for windows, but I'm a linux geek. You should still be able to do much of what I'm talking about with a normal windows command prompt.
Tagging: Make sure that you use sensible tagging on your calls to Log.d(). A reasonable policy might be to use the fully qualified class name. I usually chose something smaller than a full package prefix, but something that should be pretty unique to my code. Also, you should be sure to use a static constant to define your TAG class by class. Here's a code snippet example of what I'm talking about.
private static final String TAG = "MyProjectActivity";
....
Log.d(TAG, "Beginning process X");
Path: Make sure that your path is setup to use adb. You can try the following command to find out:
> adb devices
If you get an error about there not being any adb found in your path, you will need to add the {android-home}/platform-tools directory to your path. Let's say your android-home is at /opt/android. You can append the directory to your .bashrc file.
> echo "export ANDROID_HOME=/opt/android" >> ~/.bashrc
> echo "export PATH=$PATH:$ANDROID_HOME/platform-tools" >> ~/.bashrc
> . .bashrc
The last line will run your script and set the path.
Piping: I like to redirect the output from logcat into a file called logcat. That way I can tab complete the word logcat. (I know, minor savings, but I love tab complete).
> adb logcat > logcat &
Notice the & at the end. I also like to run logcat in the background because there is almost always an absurd amount of information flowing throw a device's logcat stream. This can overwhelm the terminal shell and/or make it impossible to see what's happening, which brings me to the next point.
Filtering: Invariably, I usually want to focus on one particular piece at a time. That's where grep comes in super handy.
> tail -f logcat | grep {TAG}
You can use any tag that you include in your code. Actually, you can grep for any substring or regex that you want to find, but grep will default to substring matching unless you include one of the regex options like -P (for perl).
Also note the tail -f logcat. That command follows the end of the logcat file as adb writes to it in the background.
Permissions: For some phone-dev box combos, adb has a hard time connecting. I've found this almost always a result of adb not being started with the right permissions. To determine if you have permissions, connect your device, then try:
> adb devices
If you don't see anything, or it says "waiting for device", you likely don't have permissions. You should shutdown adb and restart using sudo.
> sudo adb kill-server
> sudo adb start-server
You'll need to enter your admin/user password to activate sudo, but it generally caches for some amount of time, so you'll probably only have to do that once. On linux boxes (and probably macs), you can setup your machine to always start adb as root. Here's how:
> sudo echo "{ANDROID_HOME}/platform-tools/adb start-server" >> /etc/init.d/adb.sh
You should likely include the full path to adb since the path and android-home may not be set when this script will run. By the time you login, adb will already be running.
If you get creative with your tagging, you can gain a lot of power over your code. I've had times where I will have 3-4 terminal shells open and in view, which allows me to watch each component I'm testing in parallel. That's when you really feel the power of logging that a debug shell just can't do.
Location Dampens Virality
I was recently pondering the success of services like Instagram, and it seems pretty shocking how well they are doing. If you pitched me the idea about a photo app that allows users to add filters and share with their friends, I'd ask 2 questions. First, how is that different than Hipstamatic? And second, are these filters really enough of a value add over just sharing a regular picture with Facebook that it can make a viable business doing that? Yet the standard viral app formula works wonders. You take something that everybody can do (taking pictures), add some bells and whistles (color filters), and then plug that into social networks. When people open up the picture, they are prompted to join the fun and propagate the virus along. If even one person from your social network joins and pushes it along, they say you have a virality coefficient of 1, and your app will be able to sustain itself indefinitely, so long as there are one or more people who continue to propagate the app out to their friends and followers.
Consider another hugely successful startup from the last couple of years, Foursquare. While they did explode like wildfire, and it was largely due to a virality coefficient greater than 1, think about most of the status updates you see from your friends on 4sq (or gowalla or yelp). Do I really care that somebody just checked into Grand Central Station or JFK? Do I care that they found some new Sushi spot in LA? Does seeing these updates make me want to use Foursquare any more? Is there really anything I can do with that update? Sure, I can play the "game" to go get my own mayorship at a place near me, but who cares? What I've noticed on my own social networks is a steep decline in check-ins. The novelty has worn off for most of my friends. They either aren't posting their check-ins as much, or FB is just filtering them for lack of likes. Still, people say that location will be huge, and I tend to agree with them, but don't expect the same formula of virality to hold true for these types of services.
Let's consider another recent entry into the Location Based Services field, Color. They shocked the world when the news broke about them raising $41M in funding, pre-revenue, and pre-launch. And when they did launch, it was mostly crickets (and still kind of is). They even pulled their Android app after getting an average of 1.5 stars over thousands of angry reviewers. The problem is that location dampens virality. My friends from all over the country cannot physically help populate my local bar with fun and interesting photos, nor can they populate any kind of media stream near me.
I say that location dampens, rather than eliminates, virality, because everybody has some of their online friends near them in meatspace. If I build some kind of treasure hunt game that involves people placing virtual treasure around a city for others to find, you could still hope that some of your friends could actually find it. But you have to multiply the probability that somebody will take action by the percentage of people who CAN take action. That's the dampening factor, and is important to factor into your usage projections when you consider building a location based service.
Consider another hugely successful startup from the last couple of years, Foursquare. While they did explode like wildfire, and it was largely due to a virality coefficient greater than 1, think about most of the status updates you see from your friends on 4sq (or gowalla or yelp). Do I really care that somebody just checked into Grand Central Station or JFK? Do I care that they found some new Sushi spot in LA? Does seeing these updates make me want to use Foursquare any more? Is there really anything I can do with that update? Sure, I can play the "game" to go get my own mayorship at a place near me, but who cares? What I've noticed on my own social networks is a steep decline in check-ins. The novelty has worn off for most of my friends. They either aren't posting their check-ins as much, or FB is just filtering them for lack of likes. Still, people say that location will be huge, and I tend to agree with them, but don't expect the same formula of virality to hold true for these types of services.
Let's consider another recent entry into the Location Based Services field, Color. They shocked the world when the news broke about them raising $41M in funding, pre-revenue, and pre-launch. And when they did launch, it was mostly crickets (and still kind of is). They even pulled their Android app after getting an average of 1.5 stars over thousands of angry reviewers. The problem is that location dampens virality. My friends from all over the country cannot physically help populate my local bar with fun and interesting photos, nor can they populate any kind of media stream near me.
I say that location dampens, rather than eliminates, virality, because everybody has some of their online friends near them in meatspace. If I build some kind of treasure hunt game that involves people placing virtual treasure around a city for others to find, you could still hope that some of your friends could actually find it. But you have to multiply the probability that somebody will take action by the percentage of people who CAN take action. That's the dampening factor, and is important to factor into your usage projections when you consider building a location based service.
Monetize Abuse
There comes a time in most Google App Engine developers lives when they blow through the free quotas, leaving them done for the night.
Sometimes, you will run into systems telling you to "enhance your calm", or that you are "suspected of abuse". My fix is data, and as much as I can get. I need something to mashup the next new and cool app.
But I'm a good netizen. I've donated to Wikipedia. I don't steal software, movies, or music for "free" on the interwebs. Somehow when it comes to data, I can't help but consider the good that can accompany the bending that goes with hacking. It would be against reason to disallow it. If anything, it's a complement letting them know how much I like them.
The solution for Google is just to add more APIs that they track quotas on. For example, say they allowed you to pull from the custom search api. The first N hits are free. Then it's $X per M hits. This is the formula they already use for every other service they offer. Whether that's sending email or storing data, there are quotas and prices.
Additionally, if Google let you pull and store all that data, you'll be burning more CPU and filling more of your datastore quota. So at the very least, Google should loosen up when the hits are coming from their own servers.
The real utopia of app development would be a framework where developers can choose from a wide selection of APIs, available in a market, with service providers setting quota prices and consumers selecting the APIs that fit their needs and their budget. You could take this a step further and eliminate services you don't need. If your app doesn't send email, why should you even have to see that in your quota summary?
If you believe in Google extending more of their fantastic services via App Engine APIs, drop a comment. Let's see how many people like it.
If we're lucky, we can justify our abuse.
Subscribe to:
Posts (Atom)