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