Greetings,

I worked for Friendster during the time they couldn’t scale, and when they made the transition to their new architecture… I was brought in to work on side-projects, and had nothing to do with the core site at the time. (It was helpful that I was comfortable with Java, C++ and PHP, and so was ‘neutral’ on the topic.)

Mr. Lindstrom said of the problems, “I wish I could explain why—I have no idea why it happened. For a number of reasons we had trouble scaling for almost a whole year.”

I’ll freely tell you why; there was a long-running political internal battle between the people who wanted to stay on the Java code (partially written by the original CEO) which wasn’t performing well, and was hell to maintain (think all the HTML embedded in .writeln’s in the Java code, and really bad arbitrarily constructed SQL, so you could never figure out where it came from to tune), and a pretty clean ‘no-shared-data’ PHP+CSS model built by some decent web devs.

The screaming arguments usually centered around matching the old interface precisely, and until it matched bug for bug and everything, the old school didn’t want to allow the changeover, and they had (also historical) management support.

Finally the CEO gave up (or was guided to give up by his *killer* board and investors, I don’t know), brought in new management who quite promptly pulled the trigger, rearranging some engineers who were tied to the old methods and unwilling to migrate into a ‘back end’ team to build services for the web-devs. The rift between the ‘old timer’ engineers who stuck around working on the back end, and the ‘new site’ engineers never healed, with bad blood and no communication being the norm. From what I saw, they lost >50% of their engineering staff, several good managers, and at least two CEOs in the process, and thrashed trying to find a revenue model.

Friendster was a case study in how not to handle a technology transition internally. Externally it went swimmingly once the trigger was pulled.

-- Morgan Schweers, CypherFOX!