Google Wave and the Difficulty of Radical Change 179
cedarhillbilly writes "An article by Matt Asay in the Register takes on Google Wave from the perspective of visionary change versus incremental change. He suggests that visionaries should focus on smaller transformations of our day-to-day lives rather than leapfrogging. 'Much as it may want to radically change the world for users and developers, radical change generally happens over time, through a series of incremental, unexceptional edits to existing technology and processes.' Perhaps Google sensed this when they famously said they were worried about having too many geniuses. Asay revisits the point that the open source development model necessarily builds on a community of contributors and users, and not the mad scientist in an ivory tower."
"worried about having too many geniuses." (Score:1, Interesting)
Yes, all those glorious geniuses who never found a way to make Wave work... more like pretentious geniuses.
I hate the word genius. There isn't a thing alive on Earth known as a genius. A true genius would be capable of doing anything thrown at them given the right things to do it with.
Google just has people specialized in certain areas of knowledge, with decent intelligence. Yes, there might be some people who can give you an IQ of 200, but that doesn't mean a damn thing since said IQ can vary in meaning between everyone.
Some can be great with numbers but awful with equations, great with spacial awareness but awful at remembering where to go in said space.
Want to know why Wave failed? Google, an advertising company, never advertised it enough. They never gave it enough time either.
It wasn't an issue with UI, yes, it was awful, but it worked. People use bloody Facebook and Microsoft Project every day and they have to have the worst UI annoyances in existence.
Not only that, their expectations were set WAY TOO HIGH.
They never made it that accessible from the beginning.
They released its existence way too early.
Google are always too focused on stupid shiny bells and whistles at the expense of speed, WRONG WRONG WRONG.
They also had way too much going on in the UI, event handlers flying out the nose especially.
Too many event handlers were the main reason for Wave slowdowns when they get larger. Worse yet is the fact they had fade-in animations, and real-time message updates pretty much just kicked it in the nuts when it came to speed.
If they integrated it in to Gmail, or even replaced the Gmail UI with something based on Wave (conversation system in Gmail would benefit from that), THAT could have worked.
Who knows, maybe they might still get it working. But at the moment, they have been a massive failure when it came to dealing with Wave.
It was a failure before it even got a chance. The doctor couldn't save the poor kid.
Re:They killed it too early (Score:3, Interesting)
No, it doesn't, at least according to this rule: "Any software in this century that reinvents the scroll bar deserves to fail" - http://www.scottberkun.com/blog/2010/lessons-from-wave-and-kin/ [scottberkun.com]
Failure after 3 months? (Score:5, Interesting)
Google Wave was a collaboration tool, and that made it nearly useless during its limited preview. It was available generally for less than three months before Google killed it. That would be a ridiculously short time for any new service, let alone for one that actually requires network effects to become useful.
I don't know whether Google Wave would have replaced E-mail or chat; it had the potential to do that, but that was far off. But it was an excellent collaboration tool. It could have been Google's replacement for Sharepoint, Lotus Notes, and systems like that, and it looked like it was on track for that. Incremental changes to GMail are not going to cut it.
With killing Wave, Google killed something that could have become quite important for them in the future. And they also killed the good will and trust of a lot of developers and users.
Google should have given Wave three years, not three months, of general availability.
technology for other apps (Score:4, Interesting)
KDE 4 (Score:3, Interesting)
Re:I couldn't disagree more (Score:3, Interesting)
I don't see any benefit to integrating email into the Wave system - I wouldn't want to interactively create an email message,
That's not the only thing you could do with it. Since it had extensions, you could easily embed, say, a map, a calendar meeting, or a survey into a Wave. Tools to embed these things into email are cumbersome, nonstandard, and not necessarily secure. Having the concept built-in has some advantages.
It's also useful in that if someone's not online, it can behave like email, much better than IM offline messages for the same purpose. But when someone is online, it simply and naturally flips to IM. It's nice that Google Talk is in Gmail, but it's not truly integrated -- I can't immediately continue an email conversation as IM, or vice versa.
Re:technology for other apps (Score:2, Interesting)
I absolutely agree; one of my biggest frustrations was trying to get people I know to join so I could try it out. By the time I got the fifth person to sign up, persons 1, 2, and 3 had gotten bored with it and didn't want to give it a shot with more people involved.
I really think it should have been made a part of Gmail so that anyone with a Gmail account could get on the bandwagon and give it a shot, rather than expecting people to sign up for this new scary thing where they have to open *yet another* link to check each day. It's like forums - people say "I'd rather join an e-list so I can just check my email and see what's going on, instead of going to another website."
I think it really had potential and I wish email had been like this from the beginning; but it's a *collaboration* tool. How am I supposed to really collaborate when only two people I know have joined and are willing to try it?
Bad examples (Score:1, Interesting)
And perhaps you are proving TFA's point. In all those cases the development of the new alternative didn't happen at once and was a succession of incremental changes over the previous technology.
Take GUIs; OSes like Windows 1 ~ 3.11 made heavy use of CLI as well (and you might remember that Windows didn't really take off until 3); Windows 95 was still mostly a front-end for a particular version of DOS (7, IIRC); even nowadays there are a number of things that are done through the command line. Same with Mac OSes and let's not forget Linux there.
Horses weren't replaced by Ferraris either. Primitive cars were hardly an improvement over horses, and in fact the development of engines happened over the course of centuries (seriously, experimental steam-powered vehicles existed as early as 1672).
Calculators have been in development for centuries as well. Think of the Antikythera mechanism, but also of Pascal's mechanical calculators from the XVII century, and so on.
The lightbulb itself has a history going back at least 80 years until Edison made it work well enough to be a commercially viable alternative.
In short, judging form these examples, it would appear that slow, gradual change is exactly what allowed these technologies and inventions to succeed. We might look back and say "oh, the car is totally better than the horse", but it was a long time since cars first started being developed until this became true.
Wave's problems were about control and lack of it (Score:3, Interesting)
Google did a great job creating an open protocol. But they made two mistakes:
1. They were not open enough. Although they had suggested that people would be able to build their own clients (and demoed a curses based client) they never opened an API for writing a wave client. They wanted it to be a flagship web application - but just as people like all sorts of different clients for email (even if many now like web clients), they would probably have liked client choice for wave - especially if 3rd party clients had shown waves along side email and the like.
2. They were too open. Their programming model for wave (web-hosted applications with read and write access to your wave) had huge security implications. It was not clear from the UI who would have access to your data and when.
Both of these were things that slowed adoption of wave.
Wave fails if bad; but revolutionary change works (Score:4, Interesting)
In regards to the original topic, "Revolutionary" change, especially in software, is often remarkably... effective in sweeping away the ghosts of the past which weigh upon the minds of the present.
As example, a gem from the days of Wang [ephblog.com] which I just came across:
As an example of this strategy, a frustrated developer wrote Wang’s second generation e-mail system (Wang Office) over a long weekend. In his view–and he was right–the official spec meetings were taking too long. So he decided to cut through the bullshit and just code the thing (he’d designed Wang’s first generation e-mail system, Mailway, so he knew what he was doing). He sent out the new code to several large accounts, they loved it, and started calling headquarters asking, “We have the checkbook out–how do we buy this great e-mail system?” Back at headquarters, everyone (except for Steve) was going, “Huh, what are you talking about?” Once management realized that (1) customers wanted to buy it now and (2) doing it the “official” way would take another 18 months, they swallowed their pride, shot the official project, and gave Steve a small official slap while privately lauding his initiative.
/me files Matt Asay in the [bullshit|?|clueless|lost|confused] category.
Re:KDE 4 (Score:3, Interesting)
Nope. KDE 4 failed because the core developers saw themselves as smarter than their users. They saw KDE4 as a hobby project that they did for their own personal challenge; because they knew the code, they knew what it needed to become, users' needs (and expressed preferences) be damned.
Re:Too many geniuses? (Score:5, Interesting)
Promise your existing customer base ('everyone') a miracle (vaporware) product that will do everything that they ever wanted. Promise it next year. That way, when your competitors come out with a real product that does most of what your customers want -- or even all of what they really need, you can convince their CxO to "just wait until next year when our miracle product comes out -- then you won't have to deal with migration issues, etc.".
Then you can slowly move the target -- both what your 'miracle' product does and when it will be out -- until your promises and reality jive. By then your competitor's product will be easy to pooh-pooh as 'only slightly better than what we've got' and needing all of that migration work, etc.
Rinse, repeat.
Microsoft took a big hit with Longhorn -> Vista because Vista turned out to be such a massive dud. Now, MS is going to have a hard time convincing people to believe any of their long-term promises about much of anything.
Google What? (Score:2, Interesting)