This is another take on the question posed a few weeks ago about why MLSs don’t innovate. In this case, let’s take on Google. What? I can’t be serious, right? Google, a lack of innovation? Well, yes, I am serious. Case in point: Why doesn’t Google Reader support authenticated feeds? This should be a trivial task, right? I love Reader but it frustrates me that it doesn’t handle the authenticated feed from our private intranet. Worse, Google’s own Gmail application throws off a feed that can’t be read by Google Reader. Hmmm.
Clearly, the problem is greater than at first appears. Even Google is subject to the complexities of disparate applications not working well together. Different teams have developed Gmail and Reader. This same disparity is evident between Gmail and Google Dashboard, as the two just don’t play well together. Undoubtedly, there are a myriad reasons why Google hasn’t implemented authentication into Reader yet and why Gmail and Reader and Dashboard don’t work well together yet, but they boil down to this: When Gmail was written, no one had thought about Reader or Dashboard yet. So, decisions were made back then that make integrating them difficult today. This will only get more and more difficult as Google’s applications mature and as they buy more products from other companies. The bigger you get and the more products you have, the more difficult it is to make things work together easily and one more reason software is hard.
I don’t suspect corporate oversight or the lack thereof has anything to do with it. Reader came out long after Gmail and the fact that the two do not play together is endemic of a far larger challenge in software development than oversight.
I totally agree. Its why I’m worried about Trulia and Zillow: As they continue to launch more and more “features” they will be forced to compartmentalize their engineers and your two Google observations are perfect examples of what happens after that happens.
I think one way to prevent that from happening is to swap team members often. So some engineers from the Google Reader would work for the Gmail team and so on. Yes, it will be expensive to pay for engineers to go in and out of systems but its necessary if a truly cohesive set of products / features are sought.
I more meant that the private projects don’t benefit from common corporate software directions like interoperability. Odds are that the Reader originator didn’t have much (if any) interaction with the GMail originator, and each likely only got a corporate once-over (for UI conventions, documentation, etc.) as release approached. This runs afar from the process for similarly diverse developers (Adobe, Microsoft, etc.), where coupling is given consideration well in advance of release.
-Matt
I don’t think ‘innovate’ is the right word. Google creates a lot of unique new products, which is the definition of innovation. The lacking features you mention are what come after innovation — the polish and fine-tuning it takes to move from a bunch of gee-whiz features to an elegant and cohesive finished product.
You’re right, Matthew. Innovate isn’t the right word. I chose it only in comparison to my earlier post on “MLS innovation.”
8:10 am
Part of the problem is undoubtedly the level to which Google will incubate employees’ pet projects (20% research time goes a long way) without “corporate oversight”. I’m sure some of these apps got polish before being shown to the public, but I’ll bet it wasn’t much more than that.
GMail was just such a project, used internally as a client for years (dogfooding?) before seeing the light of day.
Looking forward:
http://ruscoe.net/blog/2006/07/whats-in-googles-sandbox.asp
-Matt