How the engineer driven culture at Google damaged Wave
25hoursaday.com
25hoursaday.com
1) Add something
2) Change something
3) Remove something
The paper talked about how most civil engineers have a strong bias toward 1, followed by 2, and then rarely 3. The first thought is almost always to add something. Something is wrong? That means we need something more to solve it, right?
Complexity is not a virtue. It's actually a vice and a liability. It is better to solve a problem by removing something than by adding something. This (along with losing sight of what customers want) is the problem with engineer-driven design. Engineers like to add stuff, not remove stuff.
Wave always looked horridly over-complex to me. The protocol was a tower of babel. It was "open," but it was so complex that nobody would bother climbing its learning curve. It tried to solve too many problems at once, it was slow, and it was cumbersome to use. Those are all signs of over-engineering.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
- Antoine de Saint-Exupery
It does seem to be a major problem with a lot of Google's latest inventions - they try to do too many things at once, and solve too many problems for too many people. Wave as a technology proved to be extremely useful in some certain circles, including corporate collaboration. I would wager if they marketed as a sharepoint competitor and increased the integration with google docs, it could potentially have been a money maker while giving more credibility to Google Docs.
Similar situations are going on right now with Google Buzz and even Google Mail, the execution of the "make phone calls from your mail box" seems to leave a lot to be desired. It's a feature that tries to jump out at you and grab your attention as if saying "Hey look at this, we invented something new" when really it should be almost invisible until you need to use it.
Doesn't this imply that _nothing_ is always perfection. The quote just seems to be flat out wrong.
While maybe not as elegant, but wouldn't it be better said as "Perfection is achieved, not where is nothing more to add, but when there is neither more to add nor anything to take away".
Maybe the quote has a proceeding sentence that makes it clear.
And this presumes that the requirements lead to perfection. What is the goal of the Mona Lisa or Dante's Inferno? Could Micaelangelo have done less to satisfy the requirements for the Creation of Adam?
Can you point to any value in that quote?
And let me extend my last question. How many things can you list that would be perfect merely by removing things? I don't think there are many. I suspect most things, that even accomplish a goal, lack perfection due to an array of things, not simply due to having too much of anything.
But this is exactly the type of reasoning that this silly quote leads to. That simply having less makes something better.
Apple could easily make a computer with no keyboard, no mouse, no OSK, no visual display. Simply a touchpad, to input a binary code that corresponds to text and numeric output that corresponds to what color and x,y location to draw pixel. Of course, this numeric output would simply be a binary light. But that's just stupid.
The reason you add something is almost always because there is a goal that you'd like to accomplish. Yahoo probably thought you should be a click away from your email account. Google doesn't.
“I'm sorry I wrote such a long letter. I did not have the time to write a short one.” - Abraham Lincoln
The point isnt to have less, its to have as little as possible required to perform the function you want, anything extra is just extra mental energy required to be able to understand it.
Have you ever written something and then vastly reduced it because you realise you are conveying the same thing in different ways, or written software and realised you have made 2 ways to do the same thing? thats all it means.
"Make everything as simple as possible, but not simpler" -- Albert Einstein
Einstein captures the fact that you need to both add ("as possible") and keep simple. The original quote does not, although apparently some people have a preface to the quote that has a whole bunch of assumptions that make the quote work. I've never seen that preface.
Edit: actually, it appears that Einstein never said this famous Einstein quote. According to Wikiquote, here is what he did say:
It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.
Hardly as catchy! But it does make explicit the qualifier -- without surrendering adequacy -- that applies equally to Saint-Exupéry as well.
The point seems to be that creation is a process that is first additive, then subtractive. Mere agglutination is inferior.
My point is you don't add stupid stuff, but you don't blindly say not to add something, and simply look for things to remove.
http://en.thinkexist.com/quotation/i-m_sorry_i_wrote_such_a_...
That's like saying the key to being correct is to take your correct statement and not put the word "not" in front of it.
So yes, if you have perfection, actions that lead away from it are problematic. I find it idiotic that this would bear repeating, but I guess I have a low threshold for this type of thing.
- Voltaire
The point of the quote (to me at least) was to be taken more to inspire you to rethink perfection then to be taken literally at face value.
Let me guess, you're an engineer?
Wow, that sounds nothing like grad school. Or any research environment, for that matter.
In an academic research environment you only worry about that 1% - the rest is irrelevant to getting something published.
[NB I worked in academic research for six years - mostly on engineering related topics]
Being full of engineering-minded people, Hacker News has a strong bias favoring the idea that if you hack away and create an interesting piece of technology, then that is what is required for a successful startup business.
That idea is wrong. That idea is more of a love of inventing and obsession over technology rather than successful business.
A successful business doesn;t need neat technology or having brilliant engineers.
It requires a product/service meeting consumer demand at the right time in a sustainable way at a cost that enables a profit for the business.
That's where Google Wave failed. Despite a huge financial backing in engineering and promotion, people didn't want it.
The core for a successful business is not innovative technology-- it's Business Operations.
If the business operations are wrong -- ie a product isn't fulfilling a consumer demand or has an sunsustainable cost-- then the startup is going to tank. (unless angel investors keep throwing money at it, but eventually they won't anymore)
On the other hand... if the business operations are right, ie. there is strong sustainable consumer demand for the product/service and a cost enabling a profit, then the the company will prosper regardless if the engineers are decent, great or so-so.
There are plenty of companies making good profits year after year, growing there business and equity sustainably, which have just ok engineers and average non-innovative software.
It would be nice to see more startup-related articles here on Hacker News showing technology failures, not wasting money on too much engineering and the importance of the business operations side of things.
I think in part that is because with YCs backing the two guys with laptops actually stand a chance of success. If the two guys with laptops had to make it 'on their own' it would turn out to be a lot harder.
Nor, is it necessarily the best option when maximizing comparative advantage over another firm.
Nor, is implementing new technology necessarily a comparative advantage, it could be a disadvantage (ie. if the technology fails either technically or on the business side)
It's often the most difficult or worst option because of the costs and risks involved.
On the other hand, you can have brilliant business operations and virtually no innovation for decades, until a better technology comes along and tanks your business. Although investing in technology is risky, failing to invest in new technology can be far riskier.
I'm pretty sure Nokia has great business operations, but considering how they're scrambling to release a new (wait, two new) mobile operating systems in response to the iPhone, they apparently failed to invest (or invest in the right) technology.
Sometimes B isn't possible without A. Agree with the rest.
I'm reasonably well versed in technology; I know my way around a rails or python app, have a good understanding of massively parallel computing, and can explain how PageRank works. Yet as a nonengineer at Google, you get zero input on new products. Development is almost entirely handled by engineers, with very little input from the outside.
Coming from a highly integrated startup perspective, I thought it was crazy. After years of indoctrination in A/B testing and user feedback loops and agile development, a tight integration between development and marketing/customer facing teams is almost an expectation.
But when I raised the idea of bringing in marketing to the start of development, the Googlers gave me funny looks. Engineers run the show, then hand it off to the marketers to sell; there's no real mingling between the two. At the onsite weekend, where we interviewed side by side, the engineers and the marketers weren't even allowed to sit at the same table for meals. Clinging to its technical heritage is hamstringing Google today.
This seems to be his only criticism of the product, and it isn't even correct:
>It is interesting to think about all the internal discussions and time spent implementing features like character-by-character typing without anyone bothering to ask whether that feature actually makes sense for a product that is billed as a replacement to email.
This was explicitly thought about. The reason this feature was included was to fix the latency of chatting. The perceived problem is that most of the time people spend chatting is waiting for the other person to finish typing. No one quite knew what sort of social effects this would have, but by taking a poll they would have just built a "faster horse."
The issue is that the problem Google's engineers perceived simply did not exist. The latency of waiting 30 seconds for a person to finish forming their thought into something coherent just isn't something worth overcoming.
I might type something that comes across as unnecessarily harsh, which if I said it would not, because of the tone of voice and posture I took.
The timelag of allowing me to reread to see if my statement can be misconstrued is far more important in writing.
Gnu talk does this.
Fundamentally the concept of Wave seemed good, and I think there is (or will be in future) a demand for something better than email which consolidates email, instant messaging, microblogging and some project/time management features into a single interface. I think what happened with Wave was not that they concentrated too much upon the engineering but precisely the opposite. If they had spent more time engineering a slick, fast system which scales to large multi-user conversations without crashing or grinding to a halt and integrated easily with legacy email systems from the beginning to allow a seamless transition then there would have been a much bigger chance of Wave becoming a success.
Is this true?
JSON is used mainly where there is Javascript (ie. client side webpages - though that is becoming more and more inclusive these days... almost everything is a webapp (exceptions?)) - but it's schemaless (or typeless). While this is popular (eg key-value NoSQL stores, and dynamic typing in Ruby, Python, Perl), it's not right for everything. If you did want typed data, you'd probably just use XML Schema, since everything is already there.
I ask because of a startup idea based on XML Schema. It could survive XML Schema going away, but I'm not so sure about the apparent long-term trend away from schemas/types altogether. With fast-enough computers to nullify the speed advantage of static types, will the remaining advantage of type-safety be valuable enough on its own - What is the evidence for and against? Even databases are going schemaless (it seems).
I think his point of JSON vs. XML is that JSON is simpler because it is designed specifically for representing structured data exchanged among JavaScript programs. Sure, it can be used from other languages and read by humans, but the design goal was much more narrowly circumscribed than the design goals of SGML, XML, and XML-Schema.
The argument about SOAP vs. REST is not as well-developed, but I think he's saying that SOAP was doomed by its attempt to stretch XML to serve one too many masters.
Personally though I see REST as a set of principles more than an RPC standard. It seems to me that REST's success is due both to the evolutionary manner in which it developed, and the relatively simple architectural form it takes compared to the SOAP/WS-* protocol specifications.
I guess the risk is that when you end up phenomenally successful using a particular method, it becomes very difficult to go against that ingrained culture and try doing things a different way. Best example of a company combating that issue, in my opinion, is the IBM PC, where they gave Don Estridge free reign to carry out the project outside the normal operating procedures of the company which the management realised would have destroyed any chances of the project becoming a success.
It's not a metaphor about monarchs, but about horses ... but I guess nobody knows what those are anymore.
Google mainly suffers from people (including those at Google) thinking that everything they do will be big from day 1. Even though that never happened to any of their other products.
The problem of Google to me seems to be that they release something they think it's good enough and then just leave it there hoping that time will prove them right. Then one day they wake up and see there has not been any adoption, and kill it.
When Google releases something they are hardly all behind it, and seem to forget about it in a week.
Also wasn't this part of the newer Google that looked better and was primarily more product/marketing/suits driven like Buzz?
If it was engineering culture that killed Wave, engineers are ok with failing to make something better or to analyze it. Later perfecting it for a solid product/system.
I believe the product failed in the way they released it and that Google may have found the limit for how connected people want to be. Cool as it was, Wave seemed exhausting and we don't need to see people type each letter.
Waves happen naturally on the web, twitter, facebook etc. Google hurried the response to that. I do believe many components will be reused on Google.me. Also I wonder if they have any issue with GWT now that they are being sued for Java licensing on Android.
Personally I think you are completely wrong. Google is in the business of targeted ads. For that they need infos about the user. Everything else is just a trap to get you to tell them a bit about yourself. Helping you in your searches, is as important as knowing what and who you email.
Facebook, who is also entering the same market, is giving them food for thought exactly because of that. Facebook offers almost no search, but they get your infos from other means. From Google's perspective the end result is similar.