A good problem to have

The better I got at creating web applications the harder it became to create one. At first the main problem I had was how do you create a website, then it became how to change the colors and the background and then I wanted to create an interactive site with a database and then I wanted it to look pretty and so on and so forth. The list of things never ended. I surmounted each problem and found a new one to give myself, until one day I came to the realization that I could create a website without googling once. That was a great feeling to have but by this time I had a bigger problem.

The problem

I had learned just enough to hang myself. At this point I knew a lot, I knew about browsers and all their quirks, I knew about databases and the different flavors. I also knew about optimization. This was the black-hole! Anytime I set out to create my newest coolest idea I was passionate about, as soon as I sat at the keyboard I was paralyzed. I stressed about the technology I would use. I stressed about the number of database calls. I stressed about what browsers to support. I would worry for some time and then go on a quest to build the dopest app I have ever built armed with the newest knowledge I have gathered from the Internet. The problem here is that I usually never finished the project. I always got stuck fixing some obscure IE6 bug I found that arises if you open the browser and click on Microsoft paint at the same time or wondered what the site would look like if someone visited it on a Nokia 3310 (I exaggerate but you get the idea). This always stifled creativity cause I got too technical. Other tech people exacerbated this problem. Whenever I showed another engineer my site they would ring off 10 other obscure gotchas that I never thought off.

The answer

One day while discussing my frustrations with my friend Ben, we got a revelation. We realized that a lot of the problems we were trying to fix early on were scaling problems. We were accounting for the 100,000 people that would visit my site simultaneously when in reality no one knew it existed. We were accounting for all browsers that we knew existed on the planet when no one else knew the site existed. We enjoyed building things but solving these problems at the moment of creation was making it burdensome. I am not sure who pointed it out but we realized, if my site crashes because it had a million visitors, thats actually a good problem to have. That means a million people wanted something from my site all at the same time. Think about it, if I was selling bunny eared phone cases for $15 a pop and a million people were checking it out at the same time, the probability I will soon be swimming in the millions is not far fetched. So why worry about your site working for this scenario at inception when you can be a millionaire when you have this problem and either focus your life to fixing it or pay someone else for it to be their problem. I usually get eye rolls and a look of dismissal when I say this to engineers but they forget twitter had this problem.

Twitter faile whale

The fail whale

Twitter in its early days crashed quite frequently, especially when something big in the media was happening. You can argue that, that is the exact moment twitter needed to be fully functional... but they were not. With the image of the fail whale, they even seemed to be facetious about it but I bet you, engineers were scrambling in the twitter offices. They broke consistently because people loved their application too much. That love also led them to secure millions in investment which they ended up using to pay other people to solve this problem for them. Today the fail whale is something only twitters early adopters have ever seen or know about. They have grown to a multi-billion dollar company.


I am not against optimization and I am not saying you need to optimize only at the very last minute. What I am saying is that a lot of people let optimization kill their productivity and hence the project. It is more valuable to ship shit and fix later than to not ship at all. That is why now, whenever I am talking with friends and they come up with a potential scaling problem, I always reply "That would be a good problem to have".