⇥ Important lessons nobody is going to learn from Twitter
Just over a year ago, Twitter was the technical IT* industry’s favourite whipping boy—practically every talk about scalability and performance that I heard between, say, April and July of 2008 made it a point to deride Twitter for its apparent inability to keep up with its growth. I include myself in that number, as my keynote at last year’s DPC included a few sideways jabs at the Failwhale—although, to be fair to myself, most of them were directed at RoR (which, as far as I’m concerned, were entirely deserved and continue to apply today).
Fast forward to March of 2009, and Twitter is the cat’s own ass—if Jesus Christ were alive today, he’d have a Twitter account and would be complaining about Judas in 140 characters or less. Of course, the Twitter guys haven’t figured out how to make money yet—and maybe they never will—but they have figured out how to take an idea and turn it into a product.
The really important lesson that needs to be taken home here is one that developers, engineers and architects seem to forget all too often: development is secondary to design. The best technology in the world cannot fix a bad idea, and cannot be the idea itself. But a great idea backed by bad technology can be salvaged with the application of the proper tools.
A year ago, Twitter was at risk of severe failure because the technology on which it was based—whatever that was—was no longer able to keep up with the technological demands that the product was designed to generate. The fact that the Twitter team was able to fix things up and make it possible for the service to grow further simply shows that the original idea behind their product was so strong as to withstand all those difficulties and give them a chance to patch things up.
When you work on a new idea, your first job should be to take your idea to reality as quickly and efficiently as you can—remember, fail early, and fail quickly—and not to make sure that it scales to handle the 150,000 concurrent users that you will, most likely, never get anyway.
This doesn’t mean that good engineering isn’t useful from the very start: a smart developer knows how to build software quickly in such a way that it can be easily refactored at a later point to meet increasing challenges—as I said at my DPC keynote last year, there is no good reason why you shouldn’t be building your software with scalability and security in mind from the get-go. This doesn’t mean, however, that you need to go overboard and allow overzealous technical design to interfere with your time to market.
In other news: I have turned on moderation because of spam. I resisted doing so for as long as I could, but I can’t spend half an hour every morning attempting to keep up with people who obviously have nothing better to do with their time than posting bogus comments on my blog. Rest assured that, if your comment is topical, it will be moderated through.
Fast forward to March of 2009, and Twitter is the cat’s own ass—if Jesus Christ were alive today, he’d have a Twitter account and would be complaining about Judas in 140 characters or less. Of course, the Twitter guys haven’t figured out how to make money yet—and maybe they never will—but they have figured out how to take an idea and turn it into a product.
The really important lesson that needs to be taken home here is one that developers, engineers and architects seem to forget all too often: development is secondary to design. The best technology in the world cannot fix a bad idea, and cannot be the idea itself. But a great idea backed by bad technology can be salvaged with the application of the proper tools.
A year ago, Twitter was at risk of severe failure because the technology on which it was based—whatever that was—was no longer able to keep up with the technological demands that the product was designed to generate. The fact that the Twitter team was able to fix things up and make it possible for the service to grow further simply shows that the original idea behind their product was so strong as to withstand all those difficulties and give them a chance to patch things up.
When you work on a new idea, your first job should be to take your idea to reality as quickly and efficiently as you can—remember, fail early, and fail quickly—and not to make sure that it scales to handle the 150,000 concurrent users that you will, most likely, never get anyway.
This doesn’t mean that good engineering isn’t useful from the very start: a smart developer knows how to build software quickly in such a way that it can be easily refactored at a later point to meet increasing challenges—as I said at my DPC keynote last year, there is no good reason why you shouldn’t be building your software with scalability and security in mind from the get-go. This doesn’t mean, however, that you need to go overboard and allow overzealous technical design to interfere with your time to market.
In other news: I have turned on moderation because of spam. I resisted doing so for as long as I could, but I can’t spend half an hour every morning attempting to keep up with people who obviously have nothing better to do with their time than posting bogus comments on my blog. Rest assured that, if your comment is topical, it will be moderated through.
* You know, the people who actually do something with computers, instead of just talking about them.
Comments
Excellent lesson to learn. I’ve talked on this subject before and this is one of the selling points, in my opinion, at least, of using PHP as a language. For all the bashing that PHP takes as a web development language, one cannot argue against its usefulness in concept-to-prototype situations.
I think you are spot on with the notion that over-engineering at the onset of developing an idea into a product is definitely not a wise choice, but neither is under-engineering. We should all be the Goldilocks of software engineering.
- Jeff
I think design is very important, but the key idea here is take your idea to reality as quickly and efficiently as you can. Being the first into the market has huge benefits, that at times, can outweigh any other factor. Because of this, I say get a real good idea out first and pick up the pieces later. If you can spare time for a really good design it will pay dividends on the future.
Nice post, can I just commend you on the following…
“…if Jesus Christ were alive today, he’d have a Twitter account and would be complaining about Judas in 140 characters or less.”
Really made me smile
It is important to write applications with scaling in mind, but this is not the most important thing as you point out. But also i often see people who try to build websites in ways that makes very difficult the scaling of the application. If Twitter had better programmers from the start maybe they wouldn’t been in that position in the first place.
Premature optimization is the root of all evil.