Real Travel Acquired by Uptake and The Back Story

Today is the day that it has become public knowledge that my company Real Travel has been acquired by Uptake Networks. It’s been over 5 years since I wrote the first line of PHP code for Real Travel. I wanted to share a bit about my ride so far and I look forward to even more excitement within Real Travel as part of the Uptake Network.

Real Travel’s Conception

Over 5 years ago I was introduced by to Ken Leeder by a mutual friend of ours. After a few breakfast meetings with a few of us (Michael T., Christina B., and Ken L.) we put together some wireframes and I went to work in the moonlight. Six months later we had a pilot/prototype that was built by me using PHP/MySQL with some help from a contract designer who gave me some photoshop designs. (Christina also helped with some of the design.) The application was quite simple then; we had lists of hotels in destinations and a review form for hotels.

A few more months later I quit my job [yes, the link no longer works.:)] and the company was incorporated, and our initial seed round of fundingwas coming together. This was also the time that we hired a new CTO and Chief Architect (who are no longer with us.) The decision was made to rewrite the pilot using the then beta ASP.NET 2. I pushed back but other were more familiar with Microsoft technologies and won the battle. Knowing now what was coming next, in retrospect I wish I had fought harder for an open source LAMP stack that couldn’t scale.

The Pain of Learning What You Already Knew (Again)

There was a “culture” clash in respect to development and design approaches. Within three months we went from my pilot’s 5-10K lines of PHPcode and uber simple database schema, you know the kind that you can mange from the command-line without a plethora of GUI tools, to over 100K lines of code of C# and a object oriented db schema in PostgreSQL (not the built in kind of object oriented that PostgreSQL provides, but a new home grown schema that was designed for fourth normal form.)

I will never forget the day when our architect showed the database schema relation map, it looked like a ball of yarn with so many relationship lines that the shapes of tables themselves were indistinguishable as rectangles. This was my first run in with doing it the “right” way the first time fallacy, at least to this extreme. As an engineer with then 5 years of experience I expressed my concern with the complexity but was quickly extinguished by the group-think cliches like “this is how the big guys do it.”

We started to release our site weekly and launched our site at the Web 2.0 Conference Launch Pad. The development was slow due to the complexity of the database. Not kidding, it took about 10 SQL inserts in order to add a single photo to the database; tables for strings, dates, root objects, photo, photo renditions, and so on.

During the year or two following…. a lot of “fun” happened”….. and our site’s architecture was extremely brittle and we spent a good part of our time debugging strange bugs, slow queries (with at least 5 if not 8 joins in them,) and strange IIS bugs. (A very educational experience for me building the ivory tower inefficiently.)

Born Again

I was playing with a new toy on the side called Ruby on Rails and became really enchanted in the framework and the Ruby language its self. I finally felt free from the 90 second compile time and memory cache load that ourASP.NET app required between code changes. It reminded me of thePHP/MySQL days and I realizes just how horribly over engineered our system was. I started to propose a rewrite but it went over like a lead balloon, but this did not deter me. I did freelance projects in Rails and PHPjust to keep my sanity. I believed in Real Travel and didn’t want to leave; I was drawn in by the opportunity to be the catalyst for positive change the second I was given a chance. The time would come.

As time went on and our releases became more distant apart, and our site became slower and slower, my challenge to rewrite the site became that much more appealing, but it was becoming a bigger task each day. Each time I had to change a line of code I had to wait (And wait) for hours to compile the app, start it and test it, then more hours and even days to release it, I would say “if this were Ruby on Rails it would have been done a while ago.” We knew as a company that something had to be done and as a team we were unable to develop new features and move our company forward.

As a company, we were forced by the market to change our midset, and accepted that something had to be done but a port to Rails was still out of the question. We attempted to de-normalize our tables and rewrite the code base in ASP.NET and C#, but that only proved to take even more time and we were still on ASP.NET.

A New Chapter With Ruby on Rails

It wasn’t easy, but I continued to champion the move to Ruby on Rails and we started to build all of our new development on it. We ended up having two applications, the main one was APS.NET the new one Ruby on Rails. With a use of a load balancer we were able to make much of this transparent and we found ourselves spending must of out time where it could count—on the Rails application. In fact there was a time where only one Windows development machine existed on a desk in case we had to make a change to the old system we could make the change, test it, and then push the code to production. After many many long discussions and debates we finally made the decision to make the port to Rails. It was also about this time that we decided that unless we started to use SCRUM we would either all quit or jump off of a bridge.

SCRUM, Agile, TDD/BDD, Quality, and Accountability

We had all learned our lesson. As a company we went to SCRUM training and this was one of the most pivotal points in my tener at Real Travel (or in my career.) We began to form good process and better working relationships. I begin to jump into rspec and getting the quality built in to the product it was a start, each day getting better and better.

About 11 two-week sprints later (579 story points) we had a new version ofReal Travel up and running on Ruby on Rails. I had the pleasure of powering down the last windows server—it was nice after all of the pain.

Nothing was stopping us: continuous improvement, open communication, retrospectives, developer productivity, and backlog directed self organized team. Within a year we ported the system and made major improvements to our site and even started to make some decent revenue. The summer of 2009 was great for us, major traffic gains, increased revenue, and then the Google problems started. Although I did the Rails development I could not have done it without Chris Sloan and Francisco Marin as team members, peers, and heros.

Google: The Authoritarian Mime

I won’t bore you with the details in this post, but due to some spammed pages in our site Google had decided to kick us out of their index and not tell us why. Fortunately after some time we found the problem (we found and deleted some pages that were link spammed with V1agra links and had 5K links pointing into them) and once it was fixed our traffic started to come back a bit.

Then months later we had another problem with a load balancer configuration which caused our old site’s links to become 404s. This was not obvious to us right away, but like the other Google problems, it was a problems for us and affected our traffic. We fixed the problem but we were cut deeply but the two complications. Our traffic started coming back along with our revenues, but it was slower and was a long rough ride. Traffic and revenues were going in the right direction however. We knew we could get our traffic back and get things going so we marched on.

Becoming “That” Team and Company

Through the couple of years we started to tune our SCRUM process and went from two-week sprints to one week sprints, one day planning meetings to 1 hour planning meetings, and one a week releases to releasing multiple times we day with continuous release. It started to become really exhilarating when we could run an on the street low-fi paper test with the kind people of Palo Alto, come up with some up hypothesis on a change, push out a split test (aka. AB test) and then release the winner in a day. If there was a bug and it affected our site, we could have the fix out in minutes.

What Now?

With traffic bouncing back we were engaged by Uptake and I will let Tech Crunch, and the many other blogs tell the rest of the story. I consider myself privileged to be able to learn with and from my fellow team members and ride the ebbs and flos from the first line of code that I wrote on that first pilot and I look forward to the future as Uptake and Real Travel aim to provide the best travel experiences on the web.

So, Sloan, pull the next test from the top of the test queue and lets test it!


5 responses to “Real Travel Acquired by Uptake and The Back Story”

  1. David Raffauf says :

    Awesome work, Paul. You’ve certainly worked long and hard to get here. You’ve come a long way from the AudioFeast days.

  2. Dave Golden says :

    Great to hear. Good luck. I look forward to remaining in touch.


  3. Ronnie Roper says :

    Paul that’s so awesome! I remember when we teamed up years ago when you were in Sacramento area, you’ve really come a long way since then. Great job man! I’m so happy for you!!

  4. Sergei says :

    Paul, I did feel your pain with slow .NET builds back then, and I’m glad you found happiness with Ruby. As you recall, I kept saying that I’d be happy to accept any programming language, even Cobol, as long as it was proven to be beneficial for the product *as a whole*. If I stayed, I think in due time we’d found a way to integrate .NET back-end with Ruby front-end without spending “11 two-week sprints”. I admit I should have invested more in enabling faster development cycles for you. Something that I hope I learned from that experience …

    Yet I’m still big on statically compiled languages and back-end sophistication. Consider, for instance, that the company that acquired RealTravel uses a statically compiled language and a highly sophisticated DB schema on the back end. It also uses vertical search / recommendation engine approach based on PhD-level heavy machine learning – as you recall, the very things that I pioneered, prototyped, and tried to engage the whole RealTravel in, yet didn’t get enough of support unfortunately.

    Also consider that Facebook uses multiple stacks, not just LAMP. Its “secret sauce” algorithms, as far as I know, are all implemented using statically compiled languages such as C, C++, Java, and even exotics like Ocaml. Implementing them in PHP, Ruby, Python, or other dynamic interpreted languages simply would not be feasible or scalable. Not to mention that Facebook eventually had to develop a compiler for PHP to keep the front server farm cost down.

    While you perceive that what we did in RealTravel back then was “over-engineering”, I perceive that it was “under-engineering”, or perhaps it was both. You will find, or found already, that Uptake’s infrastructure and algorithms are far more sophisticated than RealTravel’s. And, you will learn that Uptake had its share of ups and downs, with technology and business disagreements and key people leaving because of that – this is just a nature of startups.

    You also can’t ignore the fact that the former RealTravel CTO went on to found yet another startup – Siri – that, once again, uses statically compiled languages (Java, Objective C) and highly sophisticated database schema and AI algorithms. Somehow this didn’t prevent selling it to Apple for reportedly $200,000,000+ (~8x the investment) after slightly over two years from inception.

    I personally attribute the RealTravel’s relatively humble exit to external factors, such as the Great Recession, which decimated most people’s budgets for leisure travel. I still have fond memories of what we did back then, yet for me the realization that RealTravel won’t make me rich came long ago, and I accepted that. I did my share of blaming (not publicly shared though:-), yet I’m no longer into that at all. I hope in time you’ll get closer to my point of view. I wish you the best of luck!

  5. Paul says :

    Hi Sergei! Happy New Year! How have you been? It’s been years. We should grab a lunch sometime and catch up on the past 4 years. I hope your family is doing well.

    I like statically typed languages too, the’re fast and efficient for projects that require them. We use some gems with c-extensions exactly for that reason and you might be surprised to know that our data/search back-end is written in Java. Uptake and Real Travel have the same application stack.

    Like you, I was happy for Tom when I heard about his experience with Siri, he is a great guy (like yourself) and I have enjoyed playing with the siri app.

    There are always two sides to a story, Sergei, and I learned a lot from the whole experience. If its any consolation to you, I have given credit back to you on many occasions regarding your ideas of getting deeper into search and becoming a search engine like Kayak.

    It would be fun to catch up over email!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: