Is platform selection premature optimisation?
“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”
Donald Knuth
Earlier today, I suggested that we should hold language and platform selection to the same standard we do with our code when avoiding premature optimisation.
The thrust of my argument was that, in relation to scalability, 99% of sites will never become so popular as to require scalability beyond that which is possible with Rails, so worrying about scalability feels like the start of big design up front.
We should aim to not be dogmatic about our selection of language or platform, instead choosing the tools to get the job done, so we can get something out there.
After all, I think it was Fred Brooks who told us to build a first version and throw it away; the inherent wisdom in this approach is that you learn far more by building something and failing fast, than doggedly sticking to a flawed design that dies a slow, painful death.
If I can return to the example of Twitter, I don’t have any references, but I think their development time was quoted at something like 4 months? That’s not a lot of time really, and therefore, it’s not a lot of time to write off in the case that Twitter doesn’t get adopted and turned out to be an idea that was DOA.
Happily for the guys at Obvious, this wasn’t the case, and now they have a scaling issue, but I bet you they know a hell of a lot more about their users and usage patterns than what they ever could have predicted if they had set out to design it up front.
Could they have not followed the same path with J2EE or ASP.Net? Sure, if you ignore the fact that they’re Rails developers and therefore are more productive with… Rails. They chose the platform that was right for them, that got out of their way and let them implement the service to see if it would even work.
Another example, Reddit. The first version was written in Lisp before being rewritten in Python – rewriting a proof-of-concept application (the cool kids call it beta software these days) into something that is “commercially ready” is not a bad thing.
I’m sure there are plenty of counter-examples where such an approach has failed, but I’m not getting into reductio ad absurdum arguments like “if your premise is true, then I could write #{compute_intensive_app} in #{slow_high_level_language}!”
View my LinkedIn profile
April 17th, 2007 at 4:31 am
Appropriate Optimization and Platform Choices
There has been some controversy recently about Twitter and its problems scaling up to satisfy a very impressive level of growth in traffic. In particular the controversy has centred on whether the choice of language (Ruby) and framework (Rails) was a w…
April 17th, 2007 at 8:48 am
Wise words, and well spoken. On the other hand, I doggedly believe that “some design, early on” deserves a little more respect. A site like Digg, for instance, wouldn’t make a lot of sense if it didn’t scale well, as is the case for many other “Social Web” sites out there. Their very raison d’etre often depends on a LOT of sustained traffic.
I have absolutely no statistics to bolster this argument, but my feeling is that a lot of good ideas have stalled on the verge of popular adoption because of scalability issues.
The problem probably isn’t wether any particular platform is more or less scaling friendly, but rather wether the team of developers (and, possibly, their financial hinterland) will be able to scramble in time to save the day. First impressions are important – after all, the rest of the web is only one click away …
At the other end of the spectrum, time-limited, narrow-market campaign sites on a budget (that’s my day job, I bitterly admit) faces a lot of the same sort of problems, but doesn’t get the same coverage.
Well, I’m off coding on my revolutionary Web 2.0 hobby project … it’s very social and it’s very much in Rails.
April 17th, 2007 at 10:07 am
Jesper, I agree… some design up front is appropriate, but if every new social startup set out to achieve scalability to myspace-like traffic levels, they would fall before reaching the first hurdle.
Remember, that was one of the things derided about web 1.0, everyone was spending big on enterprise class hardware and expensive software stacks with a “build it and they will come” approach that doomed them to failure.
The hardware is cheaper, and the software is free, but at the end of the day, it was the lack of sustainable business models that killed pets.com and their ilk.