Paul Buchheit - Latest Comments in Communicating with code

Re: Communicating with code

remove Antivirus .NET — Sun, 13 Feb 2011 23:19:17 -0000

It's really cool! BTW, I like your website backgroud.

Re: Communicating with code

3D Scannen — Tue, 13 Jul 2010 11:39:47 -0000

Fantastic article!

Best regards from Germany

Re: Communicating with code

Ankesh Khemani — Mon, 05 Jul 2010 05:58:30 -0000

Awsome post....very enlightening.... thanks paul....

Re: Communicating with code

Adfero Affero — Tue, 22 Jun 2010 12:34:42 -0000

Hi Paul,

Soooo, what do you think about Gmail lock-downs, Never had it before - I've used G for about 2 years or so - what gives in your opinion?

Andy

Re: Communicating with code

Grace J. Goodrich — Thu, 13 May 2010 11:08:18 -0000

Developments like these are very unpredictable. Just like having People Search using various networking accounts and search engines. Its really cool. Thanks to the new technology.

Re: Communicating with code

Wilma — Thu, 16 Jul 2009 23:33:05 -0000

This is interesting. VADLO comes to mind, it is a powerpoint search engine. There are good research cartoons also.

Re: Communicating with code

jeremy — Tue, 19 May 2009 13:52:20 -0000

Still interested in an answer...

Re: Communicating with code

theszak — Sun, 15 Mar 2009 00:49:06 -0000

Who are currently key development people or leadership for gmail ?...

Re: Communicating with code

Jeroen de Miranda — Sat, 21 Feb 2009 15:21:45 -0000

Paul, great idea ... this again demonstrates the power of the FriendFeed concept and it's API which is quite comprehensive.

FriendFeed is (and will become even more) THE integration tool for 'power users' on the web - integrating information streams with no programming efforts (or with a little effort; built your own twitter like UI) as shown.

This convinces me even more to stay on the choosen track: I am using FriendFeed more and more for scenarios where I have used different tools in the past. Examples:

- tracking groups of high volume twitter users (using rooms) - not using tweetdesk and similar tools; I prefer browser only tools; it makes switching from one PC to another much easier

- embedding FriendFeed rooms in other sites and contexts.

Re: Communicating with code

jeremy — Mon, 09 Feb 2009 14:32:31 -0000

Paul, still no comment? I'm really curious about what you do for products in which the cost of the initial prototype is extremely expensive.

Are those just products that will simply never get built?

Re: Communicating with code

Alos — Wed, 04 Feb 2009 22:14:00 -0000

Excellent article. I loved it!

Re: Communicating with code

Lou Lesko — Wed, 04 Feb 2009 03:47:24 -0000

I love this post. I grew up as a fashion photographer and then morphed into a commercials director. When we are in pre-production I see a lot of images of potential shooting locations. But I can't make a final decision until I physically visit the location and "feel" it. It is an occasionally maligned quirk of mine especially when budgets are tight. But there will never be a power point presentation, no matter how pretty, that will capture what it's like to being there.

It may be a stretch to compare our two industries, but I truly think you've written a axiom that is relevant in any and all. Many thanks for the great read.

Re: Communicating with code

bollweasel — Wed, 04 Feb 2009 03:00:33 -0000

Paul- I open sourced an iPhone app for FriendFeed. Check it out: http://shanesbrain.net/2008....

Re: Communicating with code

Joel — Tue, 03 Feb 2009 20:58:32 -0000

Your success selling the AdSense concept with a prototype reminds me of James Thurber's saying: "Seeing is deceiving; it's eating that's believing." I think any slide-show would have been perceived as a simulacrum by your audience.

Re: Communicating with code

mdasif — Tue, 27 Jan 2009 10:30:43 -0000

great post !!

i completely agree with you that a working prototype is far more convincing than arguments. i believe ideas without "code" is a nothing more than fantasy

Re: Communicating with code

jeremy — Mon, 26 Jan 2009 15:07:16 -0000

Paul, not a single peep? I just have a simple question. Is the the strategy you advocate capable of "communicating with code" a product like rhythmic music search?

Because if there is a 4.5 year lag between when when you want to do something like rhythmic searching, and when someone else makes low-level APIs available, then it seems to me you lose the ability to communicate with code. You're probably better off with 1.5 powerpoint slides, illustrating the idea. Otherwise, you're going to be spending a year or two writing all the code that you need to, in order to do your communication.

So I'd still like to get your thoughts on this.

Re: Communicating with code

Parag Shah — Sun, 25 Jan 2009 07:16:42 -0000

I totally agree. Prototyping is the right way to test a concept. There are way too many irrational aspects that dictate the outcome of testing out a concept with presentations and meetings.

Re: Communicating with code

treitnauer — Sun, 25 Jan 2009 03:00:57 -0000

Any plans of offering this under username.friendfeed.com with CNAME functionality so you can point it to a custom domain? Like Robert Scoble said it looks very much like Tumblr and could serve as a stream of all your friends updates or your own lifestream.

Re: Communicating with code

Gong — Fri, 23 Jan 2009 18:27:09 -0000

I actually agree with you that the style you develop gmail is the right thing to do, however it is kind of difficult to enforce people in big company to follow that style. Why? because each person in the company already has their pre-set roles, they must full fill their commitment to get paid on time. Their commitments are not necessary match with your style. Also, if you want people to follow this style, they must be super great coder, communicator and a strong passion for great product. People fit this criteria by definition is only a small fraction.

Re: Communicating with code

jeremy — Fri, 23 Jan 2009 18:13:13 -0000

I find it completely reasonable that you come from the "iterative", rather than "leap", school of thought. Personally, I think there is something to be said for both -- it's not an either/or question. Both approaches have their strengths and weaknesses. Sometimes leap innovation is few and far between, which means that one would be foolish to rely exclusively on this type of innovation; time is often better spent iterating. On the other hand, sometimes iterative innovation runs into the problem that many hill climbing algorithms face, and hits local maxima from which it is difficult to improve without a radical change of direction. So you need to have some ability to take leaps, lest you get stuck in a less-than-optimal local maximum.

Perhaps there is a better way to phrase the answer I am seeking: Is there, inherently built in to the notion of 20% time, an assumption that iterative innovation produces better results than new pathway, leap innovation? Is 20% time really, as you seem to imply, a mechanism for insuring that employees stay focused on iterative iteration, and don't spend any time at all on leap innovation?

Paul?

To slightly switch tracks for a moment: Where I think I will disagree with you is when you say "The reason I brought up The Echo Nest was to illustrate that for almost any computing problem, there's going to be something else to build on."

I think the Echo Nest example illustrates exactly the opposite point, which is that if you're really trying to do something interesting, something that you're competition isn't doing yet, those APIs are not going to exist. The Echo Nest API was released.. when.. like six months ago? And searching music by rhythmic similarity was popular when.. like five years ago?

To me, this illustrates the fact that for really interesting, innovative problems, the lower level APIs trail the high level projects by a significant amount of time. And it also means that if you are a company that is going to wait for someone else to implement the low level beat tracking API before you start building your very first demo of the higher-level project, then you're far behind the curve. Because the reason why someone else is creating that API is because there is already a need for the higher level functionality, the rhythmic similarity engine.

So I suppose it's fine to wait until someone else exposes the lower-level API. But if you competition has already built out the product by that time, because you had to wait until the API was available, then it seems like you're (as a company) not doing a very good job of innovating.

I'd still like to get Paul's thoughts on this, though :-)

Re: Communicating with code

Mark Reeder — Fri, 23 Jan 2009 15:34:32 -0000

The reason I brought up The Echo Nest was to illustrate that for almost any computing problem, there's going to be something else to build on. Starting from scratch rarely makes sense for prototyping/side projects. I'd argue that it almost never makes sense period. The faster you can get to a functional product, the faster you can figure out exactly what your finished product will be.

I guess I come from the school of thought that iterative innovation produces better results than big bang innovation.

Again, having never worked at Google, maybe I don't fully grasp the concept. To return to the boat analogy, it seems to me like projects headed as far as NE/NW would be valuable regardless of their length. Head further to either side and you're doing more to pull away from the goal than towards it. That may be fine in short bursts, but it seems like it would be hard to sustain.

At least that's what I've seen for every "20 percent time" project I've heard about. Even MacFUSE (which seems pretty tangential on the surface) fits with Mac team's mission "to contribute to the Mac community and make the Mac OS X experience better for users and developers." from the Official Google Mac Blog. It also builds on a pre-existing foundation.

Maybe there are a bunch of 20% projects I've never heard of that are bigger leaps from Google's current offerings. But isn't that exactly the problem? I haven't heard of them. If you want visibility for your project, it's going to need to fit within the bounds of the organization you're in. 5 years ago, beat detection was a much more academic pursuit that probably would have made more sense in a university or at a company like Fraunhofer.

Re: Communicating with code

jeremy — Fri, 23 Jan 2009 14:39:33 -0000

You've ignored the fact that there are APIs out there that will let you build your functional prototype on top of someone else's work.

Ok, in this particular example, the APIs from Echo Nest would be a decent way to get started with the beat tracking. I do actually know the Echo Nest guys (Brian, Tristan), and this is exactly why they released their APIs. But look.. you're bogging down with specifics, where I'm trying to ask a more general question. Maybe that's my fault, because in my illustrative example I did get too specific. But my general question is still.. what do you do when these APIs don't exist:? I think I mentioned above that the notion of rhythmic searching first gained mass popularity in the scientific literature about five years ago. So let's pretend we're having this discussion five years ago. The Echo Nest APIs didn't exist back then, and someone wanting to do rhythmic search in their 20% time would still be at square one.

My basic issue/question still holds, because I just like Echo Nest didn't exist 5 years ago, when people were doing rhythmic searching, so also does some other API not exist today, for some new idea I have today.

So the basic question still remains: Is the Google style of innovation, which is to allow employees to pursue their own wacko, unpopular ideas in their 20% time, capable of producing fundamentally new products? Or is it only capable of producing incremental improvements on existing lines of business?

You write: "Take Paul's story as an example. Gmail was a logical extension of Google Groups. It was something that had an existing code base that could be built on top of. FriendFeed was more of a tangential product that made more sense as a standalone company (in addition to offering new opportunities for its founders)."

So it sounds like your answer to this question is No. If there are no existing APIs already within the company, that offer quick repurposing capabilities, then 20% time is incapable of producing anything outside that realm. Google cannot innovate in that space, under a 20%-time managerial regime.

That type of answer is what I'm after. I'd still like to hear Paul's opinion. But yes, that is what I am trying to understand.

Because, in my mind, the whole purpose of 20% time is exactly as Paul says, above:

"This is also where Google's "20% time" comes in -- if you want innovation, it's critical that people are able to work on ideas that are unapproved and generally thought to be stupid. The real value of "20%" is not the time, but rather the "license" it gives to work on things that "aren't important"."

So if the whole point of 20% time was to enable employees to work on exactly those sorts of ideas that were generally unapproved or thought to be stupid. To go with your canoe analogy, I thought the whole point of the 20% time was to give the employee license to paddle northeast, when the rest of the company (ocean liner) is paddling north. Right? Isn't that the whole intention? But if you're telling me that Google 20% time is incapable of producing something like the Echo Nest, from within its walls, then that really seems like an extremely limited model for innovation.

It's not like rhythmic music searching is that far away from Google's mission statement. We're not talking about someone spending their 20% time analyzing the structure of stem cells or something like that. We're talking about a search engine. Musical, rhythmic searching, yes. But still a search engine. That's right up Google's alley.

But I'm still waiting for Paul's opinion. Paul?

Re: Communicating with code

Todd D. — Fri, 23 Jan 2009 11:58:02 -0000

I enjoyed this post and liked learning the history of Gmail.

Re: Communicating with code

Mark Reeder — Fri, 23 Jan 2009 09:18:42 -0000

You've ignored the fact that there are APIs out there that will let you build your functional prototype on top of someone else's work. For your example, The Echo Nest (who I have no formal affiliation with, just an interest in their product) will do the heavy lifting of analyzing the beat locations in music. Check out:

http://the.echonest.com/ana...
and more specifically:
http://developer.echonest.c...

Leveraging another company's product may or may not make sense for a deployed product (internal development/maintenance costs vs. licensing costs). However, in a prototype scenario it allows you to bypass building complicated functionality up front and confirm or deny the justification for the product's existence. Assuming the licensing costs aren't prohibitive, leveraging someone else's product should see you through public beta/initial growth phases as well (and hopefully through explosive growth and mass adoption).

You also don't need a large catalog of tracks to start as you suggest- merely a representative sample of music from those who will be seeing the prototype. As for quantization, you don't need to be fancy up front. You can look for beat hits that fall within a reasonable distance from the user's entry (maybe 1/8s on either side, maybe add bell curve weighting if you want to get fancy).

All that said, limiting the scope of 20% projects has the benefit of keeping projects within the general realm of the company's core direction. If there aren't resources to get started on your idea, maybe it makes more sense as a personal project outside of work. Maybe it would even make sense to quit and try to start your own company or find a company where your idea makes more sense. No company can do everything.

What you've described feels very much to me like a lone employee in a canoe paddling east while the ocean liner with the rest of the company heads north. Maybe the canoe is headed north-east, but the goals feel miles apart.

Take Paul's story as an example. Gmail was a logical extension of Google Groups. It was something that had an existing code base that could be built on top of. FriendFeed was more of a tangential product that made more sense as a standalone company (in addition to offering new opportunities for its founders).

To bring things back around, functional prototypes and (from my understanding as an outsider) 20% time are both very much about hacking things together and seeing what sticks. They're both fail early approaches designed to weed out bad ideas (or ones that don't make sense within the context of the business they're created in) and bubble up the good ones.

Re: Communicating with code

Technikhil — Fri, 23 Jan 2009 01:37:48 -0000

Very interesting post ! Developer communication is something I have written about as well. I have posted about my take on this excellent post here