All of the ups and downs of Twitter has me pondering if it really would have been all that much harder or slower or worse to code up the service in let’s say C++.
Back in the early days of the Net, I had lots of friends tell me to use this or that framework for building some web stuff I was working on at the time. I resisted–in large part because I knew C++ well and the various frameworks were so brittle at the time. If I stayed in control with everything and built things up one step at a time in C++, I knew I could get things done. With the frameworks, I figured I’d be spending most of my time learning their intricacies.
So I stayed with a CGI model–I tried some ISAPI stuff too–but kept with CGI for the most part. Oh, and we also built our own database and indexes–another unheard of thing.
Anyway, the product was a killer. It ran blazingly fast. It was trivial to install. And it worked well. Very well. Scaled up to very large installations too.
In some respects you could say I and the other dev lead were stuck-in-the mud laggards, by staying with C++. I guess we were. But it paid off huge. The founders of the company sold the company for a good penny and are now both “retired”–busier than ever doing things that they always dreamed of.
Looking back, I can’t say we were all that smart, just lucky. However, it did teach me a lot about creating products versus creating “products.”
An aside, a friend worked at a large competing company and worked on transitioning a C-based custom client-server app/database to an Intranet service about the time the one company sold. The product was very, very similar and probably could have been built from what we’d worked on. Anyway, the developers sold the company on the idea of porting everything to Java in 6 months as a way of getting to an Intranet-based product faster. Five years later the product was still not done and was canned. I’m not saying it was Java that made the difference; I don’t think that was the lesson at all. It was going to take a significant amount of time to get back to the level they were originally at plus add all the stuff management dreamed about having access to. It wasn’t a straight port. The Java platform didn’t magically help them avoid the issues of getting to what they really wanted any faster. It got them started faster, but not to the end goal.
I’m reminded of all of this as I read the various press accounts of the Twitter team and their work with Ruby on Rails (ROR). I’ve never used the platform/language so I have no idea what the issues are, but I can guess. And like ASP.NET or PHP or any of the others, I can imagine as much of the work in a significant product like Twitter can be about the frameworks as much as the core product itself.
That’s not a bad thing–and personally today I’ve gone more the platform direction myself using PHP and ASP.NET rather than build sites from the ground up. I’m doing this in part because this are “light” sites. Twitter isn’t (anymore) though.
Maybe ROR can keep growing with Twitter. I have no idea. But now, a couple years into it, as the growing pains keep growing the foundation question is a reasonable one to ask: Would it really have taken any longer to get to where they are now with another language? I think not.
Now maybe ROR gets you up and running very fast, but that initial speed to market (which may be critical from a business standpoint–don’t get me wrong), means proportionally less and less every single day the service stays up.
Something to think about. All this being said, it’s time I get back to my WPF development. 🙂 (Yeah, sounds inconsistent doesn’t it. LOL).