I remember reading a paper a long time ago about traffic engineering. It turns out that when there's a traffic problem you have three choices more or less:
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.
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
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.
The assumption is that you're talking about some thing - design, work of art, whatever - which is accomplishing some goal. The perfection lies in removing extraneous elements without stopping it from achieving the goal. Nothing, by itself, doesn't achieve much.
Still, even your explanation is wrong. There are obviously times when adding something is required. If a car with no engine, I need to add one. I can't simply remove a wheel.
OK, put a lawnmower engine in a Hummer... Now this simply becomes an exercise in requirements gathering. Because your retort will be the goal is this accerlation curve, this torque curver, this gas mileage, etc....
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.
I suspect Google and Yahoo don't have the same goal. Otherwise Yahoo wouldn't put a link to mail.
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.
maybe another quote will help you understand the point
“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.
I get the point, but it's a bad quote. Let me give you an example of a quote that is right on target.
"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.
Saint-Exupéry can't have meant it literally; nothing left to take away means zero. On the other hand, since zero is possible, you can make the same trivial argument against Einstein. I suspect that in both cases the original (con)text would be illuminating.
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.
Most people realize exactly what the quote is talking about, since the alternative (removing stuff until you're left with nothing, or with something barely working) makes no sense if the goal is perfection. Part of the appeal of the quote is that you have to make this realization. Just like a joke would lose its appeal if it was preceded by a list of assumptions that would explain the joke.
The problem is that what you describe is not the alternative I've heard before. It's not that you'd remove things to nothing, but rather that you don't add something that is necessary or beneficial, because there's this belief that adding things is bad. I hear this from a lot of college grads, who apparently read a blog that talks about this, or maybe read this quote.
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.
I guess I just never met anybody who didn't understand the quote. To me it says: Think very hard about what to add, and think very hard about what to remove. Of course, I realize that those who take the quote literally are not going to think very hard about which features to remove, and I'll agree that you're more likely to succeed with a product that has lots of thoughtlessly added features, than one that has none. :)
It was Pascal who said that in one of his Provincial Letters. The quote is often misattributed to Mark Twain, Cicero, and others, but I've never seen it ascribed to Lincoln. Out of curiosity, do you remember where you heard that?
In other words "the key to perfection is to take a perfect item and remove things that cause it to no longer be perfect". Clearly I'm the only person who thinks this is just flat out dumb. Why would you ever say that to someone except to irk them?
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.
The problem I have with the quote is that it makes me think he took away too many words. To make the quote perfect, he needs to add some words. And maybe he realized that too, but would be a hypocrite if he did so. :-)
I'd agree with that - I remember a control engineer telling me that the "clever" bit of systems was actually implemented in about 1% of the code. All the rest of the stuff was boring as he was concerned, but was the bit that was actually necessary to make stuff work in messy industrial environments.
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]
I'm glad to see a post highlighted here which shows the limits of bright engineers and hacking in a business. Google Wave is just one high profile example..
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.
This attitude was precisely what turned me away from Google. I interviewed for what they call the Rotational Assistant Manager Program (RAMP), which in reality is rotational and management related only in that you go through several different marketing positions.
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.
So you want to read about companies with no competitive advantages anywhere in the organization? Maybe some big firm that uses its marketshare to enforce a significant amount of revenue as opposed to better handling of operations, marketing, R&D, customer support, sales, etc?
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.
You are 100% right but that's not a popular view around here. All it takes is two guys and two laptops.
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.
Absolutely true, execution is what matters. You can make a good business from a pretty standard idea. And the history is littered with examples of great technology that never succeeded, or only saw limited success.
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.
A.A successful business doesn;t need neat technology or having brilliant engineers.B.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.
Sometimes B isn't possible without A. Agree with the rest.
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."
Really? ICQ built character by character typing all the way back in the late 90s, and users back then stumbled across basically all of the same landmines Google Wave exposed.
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.
Every single person I know who used Wave thought the character-by-character thing was terrible and wanted it turned off. A few of them actually stopped using it as soon as they realized it did this since they didn't want to broadcast half-formed thoughts to the world.
This seems pretty much like a straw man argument. The notion that Facebook concentrates upon user experience, given all the privacy wrangling and complaints about the user interface being needlessly changed or being too convoluted, seems to be not very well founded.
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.
"...integrated easily with legacy email systems from the beginning to allow a seamless transition..." Nail on the head. That is exactly why I didn't use wave more than a handful of times even though I rather like it. If I'm the only person who uses the email when everyone else uses snail mail, it's not really very useful.
Does anyone actually know Dare Abasanjo as "Carnage4Life" or is that just his years-long ploy to annoy me and undermine his credibility in any forum of consequence?
I went to Georgia Tech undergrad at about the same time as Dare (I graduated in 2004). If my memory serves, he was using carnage4life handle even back in 2002.
The second section discusses SOAP/REST and XML/JSON, saying that XML Schema attempted to solve two problems (document formats + object wire format), but it predictably became too complex. He claims that we now use REST (not SOAP) and JSON (not XML), so the "impedance mismatch" problem is now solved.
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).
If I wanted typed data, I would be more inclined to use RelaxNG than XML Schema. In some situations, XML might not be so advantageous. JSON is quite convenient for JavaScript applications. Protocol Buffers have an efficient wire representation.
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've read similar arguments here being leveled at Microsoft. Given their strong culture and hiring practices they ended up hiring people who were strong engineers. At the same time that resulted in the company developing blind spots in areas where a different approach would have been more beneficial.
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.
Frankly, this is just punditry. Nothing wrong with trying something and failing at it and moving on cutting your losses short. I give google the credit for choosing to fail this way instead of failing with, say, marketing efforts.
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.
In that case, they are suffering from the same internal-politics fratricide that Microsoft has been long suffering from. I'm wondering if Google is at the peak of their innovation curve?
Because a marketing/business driven product has never failed before...
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.
Wave as is may be dead, the technology will live on in other google products. Introducing it as a big bang was maybe not the best way, too much change at a time. But gradually it will emerge in another form.
Why? You offered a non-obvious assessment without any evidence or argumentation.
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.
I'm not knocking Google in any way. It's just that, as the article says, Google seems to be developing their new products because thee engineers think they're cool, regardless of whether they're actually commercial. In this way, Google is the Bell Labs of the 21st century.
Lots of good stuff came out of Bell Labs, modern software being one of them, C++ another. Lots of things you are looking at right now while at your computer were influenced by Bell Labs.
Google Wave could have been great if it was not designed by engineers.It amazes me that such a giant company does not put more effort into design and usability.
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.