Paul Buchheit: Communicating with code(paulbuchheit.blogspot.com)
paulbuchheit.blogspot.com
Paul Buchheit: Communicating with code
http://paulbuchheit.blogspot.com/2009/01/communicating-with-code.html
29 comments
There's definitely a cost-benefit scenario, but I think in Twitter's case much of their run-away usage has been because exactly that ecosystem exists. It's like an early adopter's wet dream. My biggest gripe with it is the rate limiting since it means I can't actually build the apps that I want to.
(I'd love to build a friend-finder for it. Theirs sucks. That's a perfect setup for our graph discovery stuff, but we need to be able to traverse several levels out to do something useful with it.)
(I'd love to build a friend-finder for it. Theirs sucks. That's a perfect setup for our graph discovery stuff, but we need to be able to traverse several levels out to do something useful with it.)
I think rate limiting is precisely where Twitter can monetize. They can sell API keys that allow for higher usage.
Off-topic, but I did see a pretty good friend finder linked to on hacker news the other day. Can't remember the name of it though.
Hmm, if you stumble across it let me know. If you've build some secondary app that people are using you can probably get away with scraping out bits of the graph along the way, but most of the ones I've seen just do some very simple counting of friends rather than trying to do anything like finding clusters or trying to figure out which of them you're not likely to already know about.
http://www.whoshouldifollow.com/
Think this is the one he was talking about.
Think this is the one he was talking about.
Yes, that was the one. I thought it gave pretty good recommendations.
Yep, they're pretty good. I'll probably play with it a little more later to figure out what the rough weights on correlation are.
Hey, I'm one of the guys who built WhoShouldiFollow. Glad the recommendations are working out for you.
The Twitter API rate-limiting makes things harder, but as a whitelisted app we haven't (yet) run into any situations where we've hit our quota or get throttled in any way.
It sounds like Alex is working on a new method to retrieve a users followers/friends in bulk which should help out a lot: http://groups.google.com/group/twitter-development-talk/msg/...
The Twitter API rate-limiting makes things harder, but as a whitelisted app we haven't (yet) run into any situations where we've hit our quota or get throttled in any way.
It sounds like Alex is working on a new method to retrieve a users followers/friends in bulk which should help out a lot: http://groups.google.com/group/twitter-development-talk/msg/...
Sorry but you are wrong. Twitter is Capitalism on the internet. It lets anyone compete and assumes the market will auto-regulate. Which is absolutely right. Although they let anyone use their API without much control, they know that if your app sucks, the market will not follow.
OK, So hypothetically...
1. I wait until there are some clear Twitter client winners. I'd expect the market will diverge on a Killer Twitter client for each platform. Perhaps there's some alternate web interfaces with killer features, such that people stop using twitter.com.
2. I buy those twitter clients. I now control maybe 80% of the twitter client world.
3. I stop using twitter.com API as the backend, and replace it with my own.
4. Twitter.com becomes pretty much moot.
Maybe it's far fetched, maybe it's not...
Alternatively,
1. Wait until 3rd party twitter clients account for a large amount of twitter traffic - say 80%.
2. Do a deal between all the 3rd party twitter clients to stop using twitter, and collaborate on an alternate backend.
1. I wait until there are some clear Twitter client winners. I'd expect the market will diverge on a Killer Twitter client for each platform. Perhaps there's some alternate web interfaces with killer features, such that people stop using twitter.com.
2. I buy those twitter clients. I now control maybe 80% of the twitter client world.
3. I stop using twitter.com API as the backend, and replace it with my own.
4. Twitter.com becomes pretty much moot.
Maybe it's far fetched, maybe it's not...
Alternatively,
1. Wait until 3rd party twitter clients account for a large amount of twitter traffic - say 80%.
2. Do a deal between all the 3rd party twitter clients to stop using twitter, and collaborate on an alternate backend.
Hypothetically?? This can already happen! Check out identi.ca. It uses Laconica
http://laconi.ca/trac/
which is "a Free and Open Source microblogging platform. It helps people in a community, company or group to exchange short (140 character) messages over the Web. Users can choose which people to "follow" and receive only their friends' or colleagues' status messages. It provides a similar service to sites like Twitter, Jaiku, and Plurk."
I'm surprised no one has taken steps to avoid relying on Twitter.
http://laconi.ca/trac/
which is "a Free and Open Source microblogging platform. It helps people in a community, company or group to exchange short (140 character) messages over the Web. Users can choose which people to "follow" and receive only their friends' or colleagues' status messages. It provides a similar service to sites like Twitter, Jaiku, and Plurk."
I'm surprised no one has taken steps to avoid relying on Twitter.
Sure, I mean hypothetically in terms of actually displacing Twitters market dominance :)
I think if Twitter put a step wrong, or start to try and monetize users, we may see some changes :/
I think if Twitter put a step wrong, or start to try and monetize users, we may see some changes :/
2. I buy those twitter clients. I now control maybe 80% of the twitter client world.
Give me an example of one person or several people who came together and bought 80% of clients built around a successful API and then controlled that market?
Give me an example of one person or several people who came together and bought 80% of clients built around a successful API and then controlled that market?
This article just reinforced how hard it is to build brilliant products inside traditional software houses. The thought of going through several rewrites of a back end and front end, prior to release, would be laughed at.
... so I connected to that ads database (I assure you, random engineers can no longer do this!)
Interesting. I guess protecting the infrastructure of a billion dollar business is worth the cost of there being no chance of another billion dollar business being discovered in this way by a random engineer.
Interesting. I guess protecting the infrastructure of a billion dollar business is worth the cost of there being no chance of another billion dollar business being discovered in this way by a random engineer.
It's not really the infrastructure they're worried about, it's their users' trust. Can you imagine the hell there would be if some disgruntled Google employee ran off with the business strategy, clickthrough data, and credit card numbers of every Adwords customer?
Paul, what are your thoughts on Joel's essay on writing specs?: http://www.joelonsoftware.com/articles/fog0000000036.html
I think both Joel and Paul are right. Most of the code Paul talks about writing took a "few hours" to write, what Joel is talking about are massive projects that take weeks of effort only to find out that they solve the wrong problem.
So, rapid prototyping: good, unspecced large projects: bad.
So, rapid prototyping: good, unspecced large projects: bad.
The only thing good about a large project that is specced that still goes wrong is that the developers can feel good about it not being entirely their fault.
In short: do whichever lets you explore the important effects faster. Sometimes a spec will make you faster and sometimes it isn't worth it. You can generalize from these two examples, but the more data points you have the better you will be able to tell when a spec will probably be helpful and when it won't.
So Buchheit was the key figure behind Adsense, too. Wow.
we re-wrote the frontend about six times and the backend three times by launch
The more I work in this field, the more I think that this is the best and quickest way to build good software.
Once you realize that everything you write is disposable, you have freed yourself to just write and judge later.
It's not how fast you get started, it's how fast you finish. Sometimes the long roads around is quicker.
The more I work in this field, the more I think that this is the best and quickest way to build good software.
Once you realize that everything you write is disposable, you have freed yourself to just write and judge later.
It's not how fast you get started, it's how fast you finish. Sometimes the long roads around is quicker.
There's a good quote from a John Carmack post on Slashdot in the same vein:
Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren't sure which way to do something, do it both ways and see which works better.
From: http://slashdot.org/comments.pl?sid=25551&cid=2774808
Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren't sure which way to do something, do it both ways and see which works better.
From: http://slashdot.org/comments.pl?sid=25551&cid=2774808
Agreed. I don't understand why more large companies understand this method...
The best way to build the best X, is to build 5 of them.. by the 5th you're pretty awesome at building X. Seems like too many people believe instead, in meticulous up front design analysis etc etc.
The other point is that in my experience, the rewrites take less and less time to write, as you know more and more.
The best way to build the best X, is to build 5 of them.. by the 5th you're pretty awesome at building X. Seems like too many people believe instead, in meticulous up front design analysis etc etc.
The other point is that in my experience, the rewrites take less and less time to write, as you know more and more.
I agree with you, but the reason is because the managers see four of the iterations as wastes of resources.
I echoed this sentiment after getting into TDD: http://akkartik.name/blog/53634708
I'm getting a Error 403 from google clicking on the link ...
http://sorry.google.com/sorry/?continue=http://paulbuchheit....
http://sorry.google.com/sorry/?continue=http://paulbuchheit....
However,
"Public APIs enable everyone to experiment with new ideas and create new ways of using your product. This is incredibly powerful because no matter how brilliant you and your coworkers are, there are always going to be smarter people outside of your company."
The only thing that worries me about this, is that in Twitters case, they have lost control to a large extent. They're not really a destination anymore. They're a backend service with a free API. They're no longer the gatekeeper. Just suppose Twitter introduces some advert tweets in everyones stream. 3rd party apps could just ignore those. Suppose twitter does something else to try and monetize... The major twitter apps could just decide to get together and pass messages between themselves instead of through twitter.
Having a public API is awesome for innovation and growing userbases, but it seems like there could be a reasonable risk and cost to that. I think a public API should not be so complete that people don't need to use your app anymore.