Paul Buchheit: Communicating with code

http://paulbuchheit.blogspot.com/2009/01/communicating-with-code.html

by paul • 18 years ago

144 29 18 years ago

paulbuchheit.blogspot.com

axod4• 18 years ago

Completely agree with the main point...

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.

wheels3• 18 years ago

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.)

arockwell2• 18 years ago

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.

jfarmer• 18 years ago

There's http://mrtweet.com/ and http://www.whoshouldifollow.com

cstejerean• 18 years ago

I think rate limiting is precisely where Twitter can monetize. They can sell API keys that allow for higher usage.

rokhayakebe2• 18 years ago

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.

axod4• 18 years ago

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.

mweatherill• 18 years ago

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.

prakash• 18 years ago

Paul, what are your thoughts on Joel's essay on writing specs?: http://www.joelonsoftware.com/articles/fog0000000036.html

aditya• 18 years ago

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.

thwarted• 18 years ago

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.

arakyd• 18 years ago

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.

edw519• 18 years ago

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.

axod4• 18 years ago

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.

yef• 18 years ago

I agree with you, but the reason is because the managers see four of the iterations as wastes of resources.

lackbeard2• 18 years ago

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

akkartik• 18 years ago

I echoed this sentiment after getting into TDD: http://akkartik.name/blog/53634708

lackbeard2• 18 years ago

... 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.

nostrademons• 18 years ago

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?

herdrick• 18 years ago

So Buchheit was the key figure behind Adsense, too. Wow.

dreur• 18 years ago

I'm getting a Error 403 from google clicking on the link ...

http://sorry.google.com/sorry/?continue=http://paulbuchheit....

Paul Buchheit: Communicating with code

Related Stories