Comment by cletus | Hacker News Reader

Comment by cletus | Hacker News Reader

Parent Full thread

It's an interesting post and raises several cogent points but it misses the biggest problem with Wave: it was a solution in search of a problem.

I say this simply as someone who was, at the time, outside looking in. I know little more than that but it had all the hallmarks of what happens when engineers are running the asylum. Here's this communication medium in which basically all other communication media can be implemented (Email, IM, forum posts, Twitter, etc). It's the kind of general solution that engineers come up with it.

I read a post from someone else (can't find it now but I think it was on Quora) who was familiar with the matter and they were saying the risk-reward thing (which this poster mentions in passing) was all messed up. Basically the incentive structure rewarded mediocrity.

I can't speak with any knowledge of those matters but I can believe it. After all, in a startup what happens if the startup fails? You find a new job. There is a strong incentive to make your runway last and get to your next funding round (or, Heaven forbid, profitability). Inside somewhere as cashed up as Google, those incentives (IMHO) disappear.

If the "startup" fails, what happens? You just move to another part of Google. What do you think the odds were that with Wave going away, any extra Wave incentives became worthless (as would happen in a startup)? Basically zero (IMHO).

Every time I tell an engineer that I worked on the wave team, I'm greeted with the same response: "Oh, Wave! You know, the real problem with wave was X". And then I stop listening, and tell them this:

I have heard that for all the values of X. Here are the most common:

- It was too hard to use / I didn't know what to do with it

- It didn't integrate with email / didn't have email notifications

- It didn't support IE

- I started using it, but none of my friends were using it, so I stopped

- It was too slow

Too late, the team spent a bunch of time talking to actual users and finding out how they were using the product and what their real pain points were. People use wave to communicate in small teams. IIRC the biggest pain point our users cited was that wave didn't support printing. The people who did get over the adoption hurdle ended up using wave a lot. (I still wonder if maybe wave might have survived if we had charged for it.)

Wave died because we were too slow to make it good. The code base consists of around 1M lines of java. With 1M lines of code, you need a giant team to get anything done, and a giant team working hard on features tends to add even more code. The wave team burned too much money too fast. And we were still working too slowly to get explosive user growth. It made lots of people sad, but Google was right to kill wave.

If I could go back in time and give advice to the team, I would say:

- Don't use Java

- Don't scale past a few engineers. You will have a much longer runway that way, and you'll need it if you want to replace email.

- The network effect will kill you unless you integrate with email from day 1.

- You don't know what you're building, so talk to users early. Like, today.

- Don't optimise for scalability until you know what the product is supposed to be

- Don't try and reinvent the scrollbar, you idiots. (So much stabbing.)

The fundamental problem with wave wasn't that it used one technology instead of another or had one feature instead of another or anything so mundane. The problem with wave was that it solved all of the easy problems with communication. Granted, it seems to have done a good job of that, and that alone created something different that maybe was worthwhile in an abstract sense but wasn't worth switching to and wasn't worth adopting in addition to everything else.

The problems we face with communication today are not ones of distribution, speed, or longevity. Currently there are some very popular forms of communication which have fundamental issues with one or many of those aspects, but ultimately those are problems which are amenable to very direct and relatively inexpensive solutions.

The real problems we face are ones of organization, discovery, workflow, meaningful semantics, and overwhelmingly managing information overload. I don't believe that Wave significantly addressed any of those issues. But only by addressing those issues can you create the sort of value for users that will drive significant adoption of your tools.

"The network effect will kill you unless you integrate with email from day 1."

Quoting Zawinski's Law of Software Envelopment

"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."

Since this is the first time I've managed to address someone who worked on Wave, I'd like to say "thank you". I thought it was tremendous, if flawed, and found it useful while it lasted.

In a team of about 6 remote workers we used it to create collaborate documents - starting with something that looked like a chat and then giong back and editing the chat into a finished document.

You may well be right that Google was correct to kill Wave, but thanks nonetheless.

I want to add my "thank you too". I used wave as a personal wiki of sorts. I added my own development journals and ideas, kept track of projects. I used it mostly as a one man team but the fact that I could share and collaborate with partners far away was the big plus. I was really sad that it was killed and now I am running wave in a box in my computer, not the same thing but it still good.

Thankyou, that means a lot to me :)

I am truly boggled that Wave contained 1M lines of code given the functionality.. No wonder it was hard to make it good..

Feels like two high-end devs could implement the 80% of it that people actually used in a couple weeks and 10-50k LOC.

Maybe I am missing something, but it sounds like Large Company culture doomed it.

It would take more than a couple weeks, but 10-50k LOC sounds about right. Since leaving google, I've rewritten wave's concurrent editing algorithm in coffeescript in just 3k LOC.

[Blatant plug: http://sharejs.org/ ]

Was there any particular reason why it ended up so huge then? Trying to handle each and every possible use/edge-case completely? Why not Java (from your previous answer)?

I loved Wave despite its warts and managed to run several extremely successful small team document writing collaborations through it, completely replacing IM, email, groups and lots of early document drafting in Docs/Word. There was nothing that anybody on the team had experience with that came close to that. We went from hundreds of emails a day and hours of IM'ing to absolutely zero of each within a week of moving to Wave.

My only real complaints were that the web client was dog slow and going from a Wave of draft-edits to a final document was kind of painful.

Never did find a use for lots of the other bells and whistles (embedded widgets things, channel bots, etc.), perhaps that's where a lot of the extra LOC went to...

The entire Wave story would make an amazing case study if Google would ever let the entire story out.

I don't think there's any one single reason why the code base is huge. Its written in proper idiomatic java, so a lot of the code is bureaucracy (interfaces, factories, managers, assertions, etc). The code that was opensourced is reasonably representative of the rest, if you're curious:

http://code.google.com/p/wave-protocol/source/browse/#hg%2Fs...

I think we should have spent more time keeping the code clean; but thats always a tough call when you have features to ship. Its easy to point to lots of things and say they were mistakes. But I worry that, had the project been successful, we might point to the very same things and talk about how clever we were.

A huge effort was put into making the client more responsive in the few months just before wave got cancelled. I'm not sure if its still the case, but at one point wave was loading faster than gmail. We were a month or so away from shipping server-side rendering of waves with progressive enhancement for editing. That made waves load in a snap. (The guys finished that piece of work and put it in the opensource wave in a box project.)

You weren't alone in getting a lot of value out of wave. We used it internally for everything. When we had meetings, we shared the agenda in a wave. People edited the wave with meeting items, and during the meeting people collaboratively annotated the agenda with what was decided, turning into the minutes. It was a thing of beauty. I still think there's a need for something like wave - it solves real problems.

When wave was cancelled, there was a series of honest retrospectives internally on different aspects of the project. I hope they get eventually get published eventually too. A lot of people were quite career-sensitive after wave. Most blog posts you see by wave developers are written by people who have left google anyway.

Agreed. Today's technology - CoffeeScript + Backbone.js + node.js-ish backend would make it a lot easier to develop something like Wave in a couple of months by one or two developers (plus maybe a designer).

Looking at the app I'm building (alone) with these tools, I could say that it's on par with Wave on the realtime UI and complexity, but the development experience is a really pleasurable one. These tools are crafted for exactly what I'm doing and it seems like they know what I want to do before I want it.

But then again, back then you didn't have these tools so I guess you had no choice but to go the 'academic' Java way.

But anyway, congratulations on this incredible achievement and also for the many lessons learned and shared with the world.

Those technologies probably don't scale well in terms of hiring.

Also, those technologies probably don't scale at all to 1000s of servers, something a Google project has to do from day 1.

(I'm not sure they'd even be fast enough on a single server. As a rule of thumb, the more technologies you put in the mix, the more abstractions there are, the harder it is to minimize the work done.)

Yes. We did work to make wave scale before we knew what features would be important to users. That was definitely a problem, but its hard to avoid scaling when you're google and the whole world is watching.

The earlier you launch, the sooner you need to do that scaling work. But the later you launch the more development you do in a vacuum, without real customer validation.

I guess you're talking about node.js . That, of course is a hot topic today, but I'm confident that this problem is solvable. That's why I called it 'node.js-ish', meaning a backend that can do similar things as well as or better than node.js.

CoffeeScript and Backbone.js have nothing to do with scale, as they are used on the front end.

The author talked about how horrible it was to have the UI written in Java (having to wait 3 minutes for a recompile after a CSS change). These two tools (plus SASS and alternatives) on the front end makes Java->Javascript totally redundant, imho.

My guess is that the Web interface only exposed a small part of the functionality. There's all that syncing and federated server goodness under the hood to take into consideration too.

-Don't use Java

Could you recommend a good alternative?

Also, could you elaborate a bit as to why not?

Every line of code adds spec inertia. Java makes you write a lot of code, which makes it super hard to redesign your project when you pivot on features.

Java works fine in enterprise software written against a strong spec. But wave never had a strong spec - It was an experiment. Inevitably, we spent a lot of time making the wrong thing.

We needed to be able to change wildly based on user feedback. We needed a light, nimbler language which would let us pivot easily and throw away code. ... And you optimise for a changing spec with a small team and a terse codebase.

Today I would recommend Coffeescript, Rails or Scala. Maybe even Go. A few years ago, Ruby, python or C++. Erlang, clojure or haskell would probably work too, depending on the team.

Very well said.

I'm just really surprised about one suggestion: C++. Even if I used it extensively and with great satisfaction back in the day, and even if I personally don't like Java, I'd like to know what would have made C++ a better choice than Java for terseness etc.

For once it would probably be ten times faster and probably be ten times more concise.

I would think if a service-oriented-architecture (SOA) were used as much as possible to modularize a project such as this to make it easier to change functionality, was a modularized approach taken or was this just one big codebase that was essentially all lumped into one big "application"? I work on a legacy Java project that has something like 1M lines of code and its a nightmare, the team I work with is finding that modularizing pieces of it into essentially individual projects (which is seamless to the end user) helps with keeping the complexity down, just curious about this as I think the Google employee who did that rant online the other day mentioned something along these lines.

I don't think the use of Java would necessarily lead to a project's downfall, I mean how are you going to scale something like this in Python if its already slow in Java?

Interesting, these are the exact reasons I have trouble using anything but Java. I don't work off specs anymore, and I can pivot/refactor in Java like nothing else I've yet used or seen. Scala might contend with this eventually but the toolset is still not quite there yet. Can you mention a few specific areas/choices where you feel it held you back?

Does Rails define so much functions that it counts as an alternative to Ruby? I would say Ruby is a pretty good/modern language on its own.

Thanks for the advise.

Wave is probably extremely connection and packet-heavy, so likely something evented, continuation-based or otherwise able to handle a large number of connections on little memory. Erlang, Twisted, Go, stackless, Racket WS, Seaside, Tir, ... potentially behind some sort of load balancer for the evented ones (and the non-multithreaded continuation-based ones) or they're going to block other requests.

I would probably implement business logic in Lua and do routing/messaging/connection handling with Erlang.

Stackless might work, it would be great for a prototype. Too bad there isn't a Python on Lua or a Python to Lua translator. The Lua runtime is soo much better and less resource intensive.

>>Don't use Java

I would say it should really be don't use GWT? Blaming entire java for a framework that is developed originally at Google doesn't seem right to me (particularly when Google Employee does that).

I didn't notice a mention of GWT (not that it wasn't in there) and I would agree if thats the case, Java is very strong for server-side development but GWT definitely can be bloated and it isn't really Java anyways, you write it in Java but it runs as JavaScript so I'm sure it loses most advantages that it would have if it really were running as Java

FWIW, I've heard many times from people who play D&D (or the like) online that wave was absolutely perfect for them.

http://www.quora.com/Google-Wave/Why-did-Google-feel-that-Go...

"Part of the deal initially was that Wave would be compensated much like a startup, base salaries were supposed to be low but with heavy performance linked bonuses which would have made the Wave team rich upon Wave's success.

During the course of negotiations and building the Wave product, the "heavily reward for success" part of the equation remained but the "punish upon failure" got gradually watered down into irrelevance, making the entire project a win-win bigger proposition."

I totally agree. Running a 'startup' in a company like Google compared to a REAL startup is like having your own room in your parents home versus sleeping in a tent under the Brooklyn bridge. One has serious ramifications, the other is a walk in the park: Putting your life on the line or not.

I call BS on all of the anti-wave comments that come out. "Problem without a solution" is complete nonsense. It was the solution to a very real problem I have, and I only have 5 friends. We still use wave daily, exclusively really, and find it to be FAR AND AWAY the best platform for group communications. It has a few bugs still, and that's to bad... but it's full of greatness.

I disagree. Wave's biggest problem was that it wasn't user friendly. If you wanted to search for open topics, you needed to use under documented search modifiers. It worked just fine for most early adopters, but never gained traction because it just wasn't accessible to a wider market.

The problem wasn't that it didn't serve a purpose. The real-time collaboration has moved to google documents, and fills a real need. That said, your analysis for the failure is pretty accurate. It was a focus on engineering over user experience that sealed Wave's fate as a case study on how to not build a product.

Reply on news.ycombinator.com