How we built SodaHead

Everyone has heard the saying, ‘you can build it fast, you can build right, you can build it cheap. Pick two’.  However, it seems that today you can have it all.

In the beginning of August I first began speaking with Jason about the idea that was SodaHead. He had three pages moc’d up that showed the concept, he had the resume, energy and passion for the idea that could sell anyone. Meeting two was at my favorite English pub, ‘The Rose and Crown’. ‘My people’ met ‘their people’ over fish, chips and beer and it looked like a go. They were marketing and we were engineering. We “opened the doors” on October 16.

During August and September I began looking at the hard part, how to make it work and survive at a scale that would be inevitable. This being my fourth start-up I knew the drill. First start researching the state of the art in web development and analyzing risk, performance and speed of development that would deliver the concept in a rapid inexpensive manor. Some core concepts seemed obvious, agile development principles, a small engineering team and leverage the open source community for all we could get. For the month of October there were 4 of us (two founders; Jason and Mike, one ops; Art and myself) sitting in a loaned conference room with cell phones. November introduced three more engineers (two client side; Bill and Tabby and one integration/backend; Eric) and an artist (Jennifre).  The seven of us moved into a larger room, a common area in the building. As of today our company is composed of five engineers (we hired one more; Justin), two ops guys (we hired one more; John) and four marketing/business folks (Adi and Jennifre).

Now to the technology stack… The core platform was easy, hardware today is a commodity and processing, memory and disk are cheap. The development environment/tools are subversion/trac, your choice of Linux and vi. After dealing with every configuration management platform known to man I must admit I will never deal with anything less than a subversion/trac combination. Subversion is a configuration management for engineers. Build management has never been easier. Trac complements subversion with issue tracking, wiki and knowledge share capabilities and we have had no real issues with bugs in either. With ViewVC we have a rock solid environment. For an engineer, the day-to-day environment is critical. I left the decision up to the engineer. For the desktop support minded this sounds like an issue. Simply put, let your engineers support themselves. We have Xubuntu, Gentoo and Fedora. For client side development it’s the conventional Windows, OSX, Linux and every browser we can find. Giving engineers the freedom to manage their own environment makes them happy and much more productive. Last the IDE. Well it’s vi. We do have one emacs guy but I won’t begin the religious war. Eric has integrated vi with eclipse to create the best IDE I have ever seen. It takes the best of both worlds and integrates them seamlessly together. The sourceforge project is called eclim.

Off to the religious wars… Yes we are a LAMP shop, why is a better conversation point. I debated my preference for Postgres with our director of ops. I really like the disk image that Postgres lays down. I like the fact that it has the features and maturity that it has and all of the development I have done with Postgres has been good. The director of ops did a good bit of research and we compromised on MySQL 5.X. Transaction throughput for the front end was the core argument. We will see how the debate finishes as time goes on.

What about the P… a little background will help clarify the final decision. I have written C for micro-kernels that are used for routing transactions for Visa International, I have built complex C++ document processing systems on Solaris that leverage the STREAMS libraries and I have built Java based systems that scaled to the n’th degree. No matter what decision was made the fact remained that the base had to scale and we needed a web framework. I can see the writing that interpreted languages are the future of web app development. Ruby is an elegant language. The rails fan base is ‘happy’ and for rapid development it is a great solution. My main concern was surviving scale for the next two years. While interpreters are gaining momentum and speed, I needed the confidence that I could get beneath the core of the language and hit the iron. It was Java’s native interface that allowed me to scale huge systems previously. Python has a clean C interface if needed and Django offered a solid base for web development. After doing some prototyping I came to the conclusion we could do this fast and correctly with Python and Django.    

So for the first two weeks of development I spent the time getting the environment into shape and working out the kinks and writing the user and its profile (establishing a security base including identity makes the rest of development move faster). When Eric and Bill showed up they hit the ground running. I have a friend who lives by the mantra, ‘make it work, make it work right, make it work fast’.  Throughout November and December we lived by ‘make it work’. The core functions of the site were completed by New Years Day.

The schema is very warehouse centric. If looking at an ER model you would see lots of dimensions and surrogate keys. Of the ~60 tables 2 have natural primary keys. Djangos’ OR mapping framework made persistence tier development quick and easy. Eric and I have worked together enough over time that we simply developed the site in a like mind.

The full text search functions on the site are not backed by MySQL. They are a nifty piece of integration work that Eric created. He wrapped Solr (The Jakarta project) with Djangos model/management interface making it so that the calling application has small modifications in the semantics to utilize the Lucene search engine.

Coding standards helped make development of the middle tier quick and efficient. Bill and Tabby made fast work of the front end. We created a number of tags and filters that enabled richer functionality in the template API’s. While Bill developed the AJAX libraries, Tabby focused on the templates. Djangos’ template engine made the separation of control and presentation clean enough that Tabby was able to develop the presentation tier quickly.

January was all about ‘make it work right’. Jennifre spent tireless hours stylizing the pages and making graphics for everything you see. Defect management and refactoring consumed most of the month. During this time Eric was also finding, correcting and submitting back inefficiencies in the Django framework.

In February we jumped into ‘make it work fast’ mode. We introduced caching via memcache, C based NLP functions from Levenshtein, PIL and PyCaptcha. Jmeter was the load-testing tool and profiling was done using kcachegrind. We have noticed inefficiencies in the cmemcache client and switched to the python client for reasons of availability not performance. February was also the alpha month. The alpha test went very well and unveiled a number of usability issues. At this point we have an amazing product that represents an unbelievable team effort developing a rich product in a very short period of time. I am proud of the work and effort put forward by our small yet efficient team and I am looking forward to our public release. At this point I only have one concern, while we have planned for everything we could think of, there is one great unknown in the world of the web…can we survive the ‘Digg Effect’?