Thoughts on Hacking


Facebook Social Applications

posted Feb 15, 2011 4:43 PM by Amin Ariana   [ updated Feb 15, 2011 4:58 PM ]

Introduction

(Aug. 25, '07) I wrote a few Facebook apps for fun. This is an opinion article I wrote based on the experiences I learned from the first few efforts, namely, an application I wrote called "Friendmates" which Facebook later implemented as "People You May Know". The observations mainly relate to the idea selection process and market analysis. Six months after I launched, in March 2008, Facebook replicated the design without attributing any credit to me. 


Four years later (2011) in retrospect, whether or not this article puts it in so many words, the main lesson is this:

Never target the mainstream customers of a competitor. 

As a startup, always carve a beachhead market segment and focus on that niche.

  1. Developer to Facebook: I got there first on friend-finding feature (CNET)

  2. Facebook Walks Fine Line With App Developers (All Facebook)

  3. Facebook and platform complementors: history repeats? (Chad Dickerson)


Motivation to do something cool

On a day in September 2007 I was thinking about an old graph problem. A friend at work came into my office with a Business 2.0 magazine, high-lighting an article about how the recently promoted Facebook Developer platform was doing wonders. Developers seemed to be in a frenzy to write applications and buy servers and bandwidth to keep up with the demand.

Ideas

A few days later over lunch I broke into a discussion about being interested in experimenting with marketing a technology product. During the impromptu session, we bounced a few ideas off of each other and decided that some of them were smart long term ideas and some were the equivalent of spam or the existing monkey apps throwing crap at each other. The most valuable thing that came out of that lunch meeting was an online spreadsheet, the creation of which we agreed on. From that day on, the 3 of us would record an idea about an application once or twice a week. Within two weeks, we had so many ideas that we had to sit down and sort out the ones with low or no value.

On that very week, I created a Google AdSense and a Google Analytics account. To this day I haven't found a good way to monetize Facebook applications using Google AdSense (I will explain why further down) but Google Analytics has been by far the best tool I have encountered as a developer who wants to break into the ad market.

Initiation

As motivated as my partners were, they weren't as up-to-the-speed about the state of the APIs out there and as experienced with writing Web Applications. With many years of experience writing apps that were very popular at first, only to fade out amidst the changes in technology, I felt that at least for the first prototype I had to go it alone. So I followed the old advice and stuck with the idea I was passionate about in the beginning: The graph theory idea.

Planning

The graph idea itself was based on the following hypothesis: Those in the society that you have the most common friends with are most likely your friends. To an ordinary person, implementing this would be equivalent to counting the number of people you have in common with the person in question, and judging by the number. This solution seemed naiive to me, especially considering the fact that not all direct friends are equal. I devised an algorithm that took into account the connectivity with each of your friends as well as the connectivity with the person in question. The paper I wrote became the recipe for the application design and without further ado, I jumped into execution.

Execution

To many people, web sites grow out of thin air. I've walked the road quite a few times and I can tell you it's not true. I spent 40 to 50 hours on average at work, only to come home and spend another 20 hours on writing the Facebook app. I enjoyed working tirelessly, although my relationships with the people around me sufferred greatly due to the fact that I started spending less and less time with them. I was mainly driven towards reaching the milestone: seeing some activity on the Google Analytics radar.

Within 4 to 6 weeks I reached the first milestone: The application was functional. Given a few of my friends added it, it was finding people I had the most common friends with and most of them I could recognize and wanted to add. I asked my friends to test the app as well and they said they could recognize their people too. It seemed like a success. The first signs of failure however, started to show up in the same way that people close to me had predicted: The application only convinced people who belonged to the cluster of friends who added it. There was a resistence to adding the application, and much fall-out rate, from people who were not part of our inner circle and therefore would not see any relevant results (not many common friends with anyone in our app). The cracks showed themselves: my application was like an inside joke that only people in my inner circle would understand.

Control

Very soon it became apparent that I was being tamed by the waves of real-life marketing experimentation. The growth rate was very slow: double each week, but falling fast. The reason it was doubling in the beginning was that people at the core of the development were very interested in spreading it among their friends. But I knew that once we all ran out of friends, the motivation out there would be very low to spread it further. New users weren't sold on it. That's when I finally learned for the first time a lesson that some of my entrepreneur friends had tried to make me understand, but it kicked in only after I had seen the mistake: If your application doesn't sell itself within the first 3 seconds, it will not succeed.

I went back to the designing stage and thought up many ways of spreading the application: Sending out notifications or emails every time somebody successfully used it, or letting people send each other messages on the app to let each other know that they recognize each other -- this was mainly done to exploit the Metcalfe's law of telecommunications network and was somewhat successful. But none of these techniques revived the application the way one would hope. Most of the competition does these things better than you anyway, and to make matters worse, I was constantly hearing success stories of ten-fold growth from my former friends and colleagues all over the world.

Close

Looking at Google Analytics traffic analysis and results, the application is still growing. Every time I throw a new feature into it, the growth rate has a spike. But it never makes me jump off of my chair. The other problem is that the kind of content I provide (matching friends with each other) makes a very difficult sell for targetted ads. Combined with 2 other facts, (1) that on Facebook people rarely click on ads and (2) that even given proper content, targetting ads on Facebook is difficult due to IFrames, this seemed like an emerging blackhole for my time. So I closed the project, while letting it live on my server, and moved on to other projects and ventures. If one day I receive a report of a huge growth spike, I may rethink things.


Lessons learned

Know your audience

You may be a Computer Science graduate or a Software Engineering guru or just a coding wiz. But your audience is probably not. During the process of developing my application, I went from taking an hour to explain what it does and how it does it to my girlfriend (a computer science graduate) to eventually 5 minutes to random friends. Consider the fact that for an application to be worth the developer's time, you need to be able to make at least a significant fraction of what you'd make if you had a full time job. For that to happen, you need thousands of clicks, generated collectively by millions of users. If you had to spend 5 minutes with each of the million of people who would be using your application, you'd be better off as a salesman in an employed position. Your application must sell itself and it has only 3 seconds do to so before your user loses interest. To accomplish that, you need to make something that doesn't require explaining. "Slap your friend" is a lot more understandable than "For reasons X and Y, you might recognize this person Z."

Test your market

You don't have to spend weeks of precious time creating a prototype to figure out whether your application may be a success or a failure. Write the first version (or a version branded differently) as quickly as you can. Release something that barely does anything, but has all your explanations and keywords, in less than a day. Release a few ideas in this minimalist way. Watch how the market reacts. Put aside your feelings and act accordingly. Each market is unique. In some markets content matters, in some humor matters and in some, efficiency. In the Facebook world, communication and efficiency are keys. The content is not. And users expect to be rewarded for 3 seconds of their time and 1 click of their effort. They're there because they're too busy to meet their friends in real life. If you make something to make their lives easier, like I did, make sure they can understand it without your explanation.

Question your commitments

Facebook is not the first platform that has come out and it will not be the last. The recent release of Google's OpenSocial platform is further evidence of that in Facebook's own market domain. The Social Networking market is to the Online Advertisement industry as Skyscrapers are to the Real Estate industry: given the same base to work with, you have decided to produce more units of communication (or living space). As with real estate, being in the right place at the right time always matters, but it doesn't necessarily matter which market you are in. All markets will grow and so will those who fill in their demands. If you are looking to be part of the paradigm shift in the advertisement industry, you need to be where the eye-balls are, or you need to attract them. Content, communication, search and etc are some of the many ways to accomplish that. The growth value is not where things already exist, but where there is under-developed property and rampant demand. Can you see the thousands of pages of a certain kind of information that don't exist? Are you going to create them one by one? Are you going to create an engine that lets interested people create them? Are you going to write an algorithm that will just make all of those pages happen? Whatever you do, once in a while take your head out of your box of believes and look around to see where people are going.

Have fun

Succeeding in the web world is half skills and half luck. If you're not having fun with it, sooner or later you're going to run out of enthusiasm and give up. If you are having fun writing code, share the fun with other interested people. If you're spending all of your spare time in the project, stop once in two weeks and catch a movie or something. Always consider the fact that your dreams of making money while you sleep may be a matter of time given your character, but your youth being limited to a few years is a matter of fact. One day you may raise your head and realize you haven't done anything in the past few years except code. You've always thought of yourself as a very interesting person, but when you socialize and people start talking about their interests, you may find yourself lost for words. This scenario needs not happen! Those who will succeed, succeed with the help of those others who had fun with them in the meantime.

Persist

On one last note, as I already mentioned, success is half skills and half luck. If you have the skills, the coin is yours to toss however many times you want to toss it, so be persistent. Keep your skills sharp and your prototypes plenty.


Applied Computer Science

posted Feb 5, 2011 6:09 PM by Amin Ariana   [ updated Feb 5, 2011 6:12 PM ]

Interesting (and not so interesting) problems

Rubik's Cube:

Rubik's Cubes are, in contrast to Sudoku puzzles, problems. They require a strategy to make choices from a number of non-trivial decisions. Recently I watched The Pursuit of Happyness starring Will Smith, with a scene involving solving the cube to impress an employer. I was intrigued -- I owned one as a child, but I completely forgot about the puzzle until I watched this movie. I decided to completely block any publicized solutions to the problem and asked my girlfriend if I could borrow her cube, and we started thinking about the mechanics.

The brilliance of the game is in its mechanics: For an hour, we both came up with different theories of how the corner pieces work. They cannot possibly be fully dependent on any of the layers in the 3 dimensions, and yet they are attached to something.

We both thought of 3 axis first. Her theory was that there are circular inner rails involved on which the corner pieces run (I later verified and her solution was correct and in fact the one used in the product) but for some reason I couldn't get my head around imagining the construction. I needed it to be simpler: a reduced mechanical problem. My 3D imagination doesn't keep a lot of information.

The first lemma I thought of was that if you have a small Rubik Cube inside a bigger Rubik Cube and then you attach each piece in one to the corresponding piece in the other using spikes, the construction would still function. It took more time to accept my own second lemma that a Rubik Sphere wouldn't be as strange mechanically as a Rubik Cube. In fact you can completely imagine a spheric one where each layer is attached to the construct using rails such as those around a Pringles chips cylinder lid -- but imagine that for each and every layer. Now if you put the first and second lemma together, you get a Rubik Cube with a Rubic Sphere center (by substitution) that works.

As for the game itself, I still haven't looked up a solution, and I'm trying to come up with an algorithm. I'm not sure yet whether it is possible to swap two pieces on the same face without replacing any other pieces in the net result. But if that is a possibility, the entire solution can be reduced to it: Since each 2 layers share an edge, the swap algorithm can be extended to be independent of layers through the use of a little bit of algebra. Once you can swap any piece with any other piece, all you need to do is to know where each piece goes. That is not difficult: according to the construction I described ealier, the center of each face of the cube cannot possibly move relative to the center. So the center of each face describes the color that face should have. That determines exactly which color to expect for any given co-ordinates. Pick the co-ordinate, decide what colors should the piece there have, find the misplaced piece with the disired colors, then "swap". Repeat for all co-ordinates that do not have their correct piece in place.

Will I come up with the swap algorithm itself? As soon as I get some free time, I will start thinking about it (today was a work day and last night I was up until 3:30 a.m. thinking) but I'm sure it will be a satisfying experience. Meanwhile, feel welcome to look up the solution from Wikipedia.

Sudoku puzzles:

Sudoku puzzles are not problems, they're incomplete solutions. At any state of the puzzle, there are deterministic and fully-recoverable transformations that get you to the next "more solved" state until you complete the solution. The space of the solutions based on the given values is very small.

The first time I saw a Sudoku puzzle, I ventured to write a program to automatically solve it. But as soon as I solved one myself I realized what most people who have tried it probably realize: the reason it is not an "interesting problem" has to do with the fact that at any decision node of the decision tree, at least one decision is completely deterministic and doesn't require further exploration; hence no "machine" learning is really involved.

This has 2 interesting outcomes: (1) Sudoku can be quite an addictive puzzle due to its nature: confirming our ability to make decisions in absence of risk, and (2) it can be an immensely valueable teaching tool to children because it keeps one of the variables (namely the seemingly-stochastic distribution of the decision values) pre-determined.

As for problem-solving value, I may move on to something more interesting. Say: the value of quantified indicators such as (1) the number of lines of code (2) the platform used (3) the skill-set of people (4) etc in predicting the relative performance of a final product. Another interesting problem is that my neighbor, who at times inspires me with her comments, took a look at this web site the other day and asked me "is it really English?"

I may have to rethink the niche audience factor.

The application gap:

My friend is a mathematics genius in the making who psychologically speaking, finds his sinful pleasures where no other would find sane enough to explore. Centuries ago he may have wanted to discover the North Pole, but in this day and age you'd find him describe a world named "Abstract", especially during quality times like our traditional trip to Montreal on new years. Shortly after I graduated, he wrote an abstract on "Primitive Galois Representations", which for me serves as a stark reminder that I use the word "sophisticated" too loosely. This year when he was talking about another abstract concept new to me, I asked him whether he saw any applications for his subjects of curiousity. He said yes; but those applications would serve abstract ends. Again there is this gap that oppresses the heart.

Going after motivation with a club

posted Feb 4, 2011 6:29 PM by Amin Ariana   [ updated Feb 15, 2011 4:27 PM ]

(Dec. '08) After returning from Europe in October, I visited family in Canada and then moved to Seattle again. I needed the mountains and the tall trees to be able to let loose and think. The dirty snow slush on the streets and the clusters of underground pathways in Toronto, while romantic sometimes, don't exactly lead to creativity. I'm working during the week in "the big company" while letting Paul Graham and Joel Spolsky seduce me back into what I really want: finding and owning the solution to a problem.

I learned a thing or two from my Groundfeed attempt: one must solve a real problem, not a hypothetical one. I will suspend that project for now and look into building something more in theme with people's needs. For probably the 7th time I real Paul's "why smart people have bad ideas" and his assertion that if you don't work on ideas, you won't have any, in "Ideas for Startups".

I've installed a Source Control server (Subversion, it's open-source) on my home development machine and while I'm thinking about ideas, I've decided to put more demand on my non-routine thought processes by starting to write essays again. I'm also interested in partnering up with good coders to collaboratively work on future projects.

By the way, once in a while you see a very small application or game that reminds you what inspired you to study Comp Sci in the first place. Bloxorz is one of those little games.

Nevermind the bollocks

posted Feb 4, 2011 6:26 PM by Amin Ariana   [ updated Feb 4, 2011 6:28 PM ]

(Oct. '08) I took some time off. I went around Europe for about 80 days and backpacked through 22 countries. It's amazing how much your perspective about life and your own ambitions changes when you get off the desk, go outside the box and talk to a few people. I might come back and do the same thing, but I'll think differently.

Haskell programming language

posted Dec 6, 2010 11:57 AM by Amin Ariana   [ updated Dec 6, 2010 2:02 PM ]

Why Haskell?

A letter from my friend Sean E. Johnson on the virtues of Haskell:

"Hey Amin,

I mentioned Haskell while I was over at your place, but I did a poor job extolling its virtues.

Basically it is a purely functional, lazy programming language. This means that the order that you write things in doesn't matter. A few practical consequences of this are that there are no "if" statements or "while" or "for" loops. These loops are instead replaced by map, filter, fold, and recursion. Also, the laziness of the language means that handling infinite lists is quite easy. For example, if you want a function that returns all the prime numbers, it's return type should be an infinite list of integers. This is ugly to do in most languages. In C# it would require the "yield" statement and iterators. Or the more traditional way would be to pass in a max value, and stop computation once you reach it. This is of course flawed because what if you do not know the max number without processing the list of primes.

Here is an simple (but inefficient) way to get the list of all primes in Haskell (primes is an infinite, ascending list of all the prime numbers):

primes :: [Integer]
primes = filter isPrime [2..]

isPrime :: Integer -> Bool
isPrime n = null (filter (\x -> x `mod` n == 0) [2..n-1])

You know everything in the code example above. The "mod" is the modulus operator (sometimes written as %).

Anyway, even though I didn't make a good case of Haskell while I was at your place, if you are interested, you should do the following tutorial: learnyouahaskell.com

If you find it isn't your thing, then 30 minutes wasted, oh well. But I did manage to convince (edited: one of our skeptical former colleagues) that Haskell is the prettiest programming language under the Sun, for what that's worth.

Enjoy,
Sean"

1-5 of 5