

Paul Buchheit: Communicating with code - paul
http://paulbuchheit.blogspot.com/2009/01/communicating-with-code.html

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

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

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

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

~~~
unalone
<http://www.whoshouldifollow.com/>

Think this is the one he was talking about.

~~~
arockwell
Yes, that was the one. I thought it gave pretty good recommendations.

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

~~~
gelliott
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/...](http://groups.google.com/group/twitter-development-
talk/msg/63c4b5bcb4891e1e)

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

------
lackbeard
_... 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
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?

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

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

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

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

~~~
axod
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
I agree with you, but the reason is because the managers see four of the
iterations as wastes of resources.

------
dreur
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.blogspot.com/)

