After logging in, be sure to visit all the options under Configuration in the Admin Menu Bar above. There are 26 themes to choose from, and you can also create your own.

 

 

Below is a chart of home prices in my zipcode taken from Zillow 

We bought our house around the peak of that chart. According to Zillow our home seems to have lost about $50,000 in value since we bought it. That seems high on the surface but I know of at least one house in our neighborhood that just sold for $60,000 less than what the owners paid for it around the same time we bought our house.

I don't expect that the recently announced home owner rescue plan by the Obama administration (which is covered in a great Q & A in the New York Times blog) will have any effect on us given that we can afford our house and aren't in dire financial straits. Unless I end up one of the 3,600 waiting for the other shoe to drop and can't find a new job. At least I'm no longer an H-1B so I don't have to worry about needing to leave the country within a week or two if laid off.

I expect house prices to drop even further before we hit the bottom. This is a rational expectation when you look at the following chart

None of this would be a concern if we plan to live here for the next 20 – 30 years. However I have a horrible daily commute and as a new dad I'm not enamored with the schools in the area. 

So I punched some numbers into Pay Or Go: Walk away from your mortgage calculator and the result was a recommendation to walk away if we don't expect the house to appreciate back to the price we paid for it in the next 5 – 7 years. Given the historical chart above, I don't.

Articles like Silicon Valley 'underwater' homeowners: Should I stay or go? point out that the biggest consequence of walking away is having a blemish on your credit score for up to seven years. This implies to me that if moving to a neighborhood whose schools I feel better about is important then it makes sense to take the credit hit now, rent a place and put away the cost savings over the next seven years so we can have a great down payment when we want to move to that house in the great school district when Nathan will be about 7 years old.

On the one hand, I feel like I'm shirking some financial responsibilities even thinking about this but on the other hand I want to do what's best for my family. What do you guys think?

Now Playing: Bob Marley & The Wailers - Redemption Song

 

…just different requirements and constraints.

The top story on programming.reddit this morning is an example of how differently people can view the same incident and how it relates to making design decisions when trying to ship a software project.

Almost a decade ago, Joel Spolsky wrote an article entitled Two Stories which contrasted his time working at Microsoft with his time working at Juno (a popular ISP from back in the day). Below is the relevant excerpt from Joel's article which talks about his time developing the macro language that was to be used by Excel.

My first assignment at my first job was working at Microsoft, where I was told to come up with a new macro language strategy for Excel. Pretty soon, I had the first draft of the "Excel Basic" spec (which later evolved into Visual Basic for Applications, but that's another story). Somehow, this mysterious group of people at Microsoft called the "Application Architecture" group got wind of my spec, which must have concerned them, because for some reason they thought that they were in charge of things like macro language strategies, and they asked to see my spec.
…
So I proceeded to ignore them as diplomatically as possible.

This seemed to piss off a guy named Greg Whitten who headed up the App Architecture group. Now, Greg was something like Microsoft employee number 6. He had been around forever; nobody could quite point to anything he had done but apparently he had lunch with Bill Gates a lot and GW-BASIC was named after him. Greg called a BIG MEETING and proceeded to complain about how the Excel team (meaning me) was screwing up the macro strategy. We pressured him to come up with some specific reasons but his arguments just weren't convincing. I thought it was nice that here I was, a new hire pipsqueak right out of college, arguing with employee number 6 and apparently winning the argument. (Can you imagine that happening at a Grey Flannel Suit company?) My programming team, headed by Ben Waldman (now a VP at Microsoft) backed me up completely, which was all that really mattered, because the programming team wrote the code and thus had the final say on how things got done.

Five years later, John Foust tracked down Greg Whitten to get his take on the same incident and then republished Greg's private response on the classic computing mailing list. The relevant excerpt from Greg Whitten's mail is below

On the Joel Spolsky subject he was a basically ignorant junior employee who left Microsoft after a short number of years. His short sighted decisions to take the VB macro language in Excel in its own directions caused 6 other major applications that were doing BASIC macro languages to diverge and not be able to share any macro programs between the applications. He made other similarly stupid decisions like creating a custom programming interface for BASIC in Excel instead of sharing a common interface as strongly recommended. The applications group spent 30 man-years integrating custom interfaces for each application with the Office 95 applications. In Office 98 they tossed it all and went back to my original suggestion which only took 1.5 man-years to develop and provided better commonality and learning between the applications.

It is instructive to compare both approaches to solving the same problem. Joel seems to be a believer in the philosophy that shipping is a feature which means you execute on your project by limiting dependencies while making sure you are building specific solutions to customers problems. Greg was big picture guy who wanted to ensure that all of the various BASIC macro languages being developed by different groups at Microsoft were compatible and could developers could easily port applications between them. They both have a point, on the one hand the designer of the Excel macro language shouldn't have to be limited by the constraints of building macros for Outlook but on the other hand anyone building common tooling or infrastructure for macros in Office would prefer that there weren't significant differences in the various macro languages in the product suite. So you end up with two smart people with contradictory goals and it is thus unsurprising that each thinks the other is ignorant.

The unfortunate thing about this entire incident is that it would have been a great learning experience for Joel if he had stayed on in Excel to see some of the consequences of his design decisions and then be in a position to consider whether he'd made the right tradeoffs in the first place. Of course, this is pretty commonplace when it comes to large software platforms where people can spend 3 – 5 years working on a single release which in combination with an average job tenure of 4 years in the U.S. (probably less in fast paced the software industry) means that many people never learn from their mistakes or improve their skills over time.

~~

As a program manager at Microsoft, I'm often in the same predicament as Joel was when he started working at Excel. Although the same challenge exists at every big software company, Microsoft is unique in its breadth of software offerings which means that almost every technology choice or design decision you make is an opportunity to pay some sort of strategy tax. The key thing I always keep in mind is that shipping is a feature and building software that delights our customers should have the highest priority. Being able to articulate how your choices reflect both of these points during every phase of the project is part of being a good program manager. Joel was able to do that, which is why he got to ship his project how he saw fit.

Now Playing: Korn - Freak On A Leash

 

Yesterday Mark Zuckerburg announced a number of interesting upcoming changes to Facebook in his post Improving Your Ability to Share and Connect which are excerpted below

What's New Today
Starting today, we are announcing new profiles for public figures and organizations. Once called Pages, these new profiles will now begin looking and functioning just like user profiles. Just as you connect with friends on Facebook, you can now connect and communicate with celebrities, musicians, politicians and organizations. These folks will now be able to share status updates, videos, photos or anything else they want, in the same way your friends can already. You'll be able to keep up with all of their activity in your News Feed. This means that you can find out that Oprah is reading a book backstage before a show, CNN posted a breaking story or U2 is working on a new song, just as you would see that your friend uploaded new photos from her trip to Europe.

We're also going to make some changes to the home page. The new home page will let you see everything that's shared by your friends and connections as it happens. It will also provide you more control by letting you choose exactly who you see among the people and things you are connected to. You can decide you no longer want to get updates from your old friend from high school who you rarely talk to, or you can filter the stream to only see updates about your family members. And now, if you want, you can read what President Obama is saying on the same page as your best friend. You can find out what it is your mother, your high school classmate or President Obama are doing, thinking and sharing right now just by logging into Facebook.

We'll begin rolling out the new home page next week, so please check out our home page tour to see the new design and let us know what you think about it. This is an exciting move for us and we have more coming, so keep an eye on the blog for more updates about upcoming products.

One thing you can say about Facebook, is that they are quick to adopt new features from hot startups once its been shown that those features have legs. Most recently, it has borrowed ideas such as the ability to post inline comments or indicate you like an item in our news feed from FriendFeed and with yesterday's announcement it looks like the company agrees that Assymetrical follow is a core Web 2.0 pattern as popularized by Twitter.

Facebook initially decided to segregate celebrities and brands from regular users with their Pages feature. Given the success that MySpace has had both from a user experience and monetization perspective from integrating brands into their social graph and treating them equally as users, I'm surprised that it took Facebook this long and that when they did it seemed this was more inspired by Twitter's success than MySpace's.

I expect this to significantly change the dynamic of Facebook especially since many people have already indicated they are fans of various brands on the site. So there are many people who will be exposed to this functionality right off the bat. What will happen when the site I used to visit to see what's going on with members of my extended family, former coworkers and high school friends becomes just as likely to be filled with marketing messages from Windows Mobile and 50 Cent because I've indicated interest in these brands?

Already, my news feed now has stuff like

which repeats a lot of the mistakes of the FriendFeed user interface such as too much space being dedicated to content I may be marginally interested in and putting people I have no interest in right in my face.

Twitter doesn't have these problems due to their core design being different. People only get 140 characters to make their point so I get more content on the page instead of half the screen being dedicated to a single update. Also I don't see @replies from people I'm not following so "me too" comments in response to content from popular users doesn't clutter my experience unless it comes from mutual friends and even then I can disable that feature.

As Facebook continues to grow, the legacy of their existing features will make it harder and harder for them to adapt to new trends. As someone who works on bringing new social features to decade old applications with pre-existing usage patterns and hundreds of millions of users as part of his day job, I know first hand how difficult things are going to get for them.

Now Playing: Bone Thugs 'N Harmony - Da Introduction

 

Yahoo! has thrown their hat in the ring and joined the hottest new trend on the Web, shipping your very own "Connect" technology. What is a "Connect" technology? David Recordon does a good job of summarizing the common characteristics of this new category of technology offerings in his post Anatomy of "Connect" where he wrote

a straw man definition of a "Connect" application:

1. Profile: Everything having to do with identity, account management and profile information ranging from sign in to sign out on the site I'm connecting with.
2. Relationships: Think social graph. Answers the question of who do I know on the site I've connected with and how I can invite others.
3. Content: Stuff. All of my posts, photos, bookmarks, video, links, etc that I've created on the site I've connected with.
4. Activity: Poked, bought, shared, posted, watched, loved, etc. All of the actions that things like the Activity Streams project are starting to take on.

In my mind, the Goals of all of these "Connect" applications are focused on helping people discover new content, people they already know as well as new people with similar interests.

Facebook launched this trend with their announcement of Facebook Connect which offered an alternative to OpenID by offering a smoother user experience and the opportunity for sites to also leverage their news feed as a viral distribution mechanism. According to the Yahoo! Developer blog there is now a similar offering from Yahoo! announced in their post Extend Your Publishing Reach with JS-Kit + Yahoo! Updates which states

Here's how it works: Integration with the Social Directory API allows JS-Kit to display a user’s Yahoo! nickname and avatar picture on the site. Integration with the Updates API allows JS-Kit to publish an item to the Yahoo! Updates feed when a user adds a comment to a web site powered by JS-Kit. At all times, your users remain in control of their data by leveraging OAuth to broker data access between Yahoo! and JS-Kit.

Yahoo! Updates allow publishers (and publishing partners like JS-Kit), to syndicate user-generated actions (ratings, reviews, comments, favorites, and uploads) to Yahoo!'s massive global distribution network. In the coming months, as Updates are implemented across Yahoo!, publishers will enjoy referral traffic back to their sites from across the Yahoo! Network (more than 500M+ monthly unique visitors).

The more of these "Connect" offerings that are announced the more they seem like introducing a new problem instead of creating a solution. Back in the day, it was easy to argue that having a button on your site is more palatable than the OpenID login box prompting users to enter some obscure URL. However when I go to places like Sun's website and see a comment box with the following

I wonder if this is progress. There are even more perverse cases like StackOverflow whose current login page looks like

Of course, this is just StackOverflow's attempt to make the OpenID sign-in process easier for users instead of having them remember some obscure URL. Still I wonder about the paradox of choice style experience that is being thrown in front of users. Whenever I go to Hacker News I actually forget which of my various Facebook/Windows Live/Google/Yahoo IDs I've previously associated with the site via ClickPass. It actually would have been easier and less confusing for me to just create a regular account on the site like did with Reddit which would also enable cookies to work so I wouldn't have to sign-in every single time.

I also wonder about the unnecessary duplicative efforts it will take sites to integrate all of these different "Connect" offerings as well especially when you consider how radically different APIs like Facebook's friends.get are from Yahoo's Contacts API. I'm typically against premature standardization but when you have almost half a dozen offerings that effectively do the same thing but with radically different APIs it may be time for standards to start showing up.

Now Playing: Domino - Sweet Potatoe Pie

 

Earlier this year I was approached about writing a book on cloud computing topics by an editor for one of the big computer book publishers. Given that between my day job and having an infant I barely have time to keep this blog updated, I had to turn down the offer. However I did spend some time taking a second look at various cloud computing platforms like Amazon Web Services and Google App Engine then trying to put myself into the mindset of a potential customer as a way to figure out the target audience for the book. Below are the two categories of people I surmised would be interested in spending their hard earned cash on a book about cloud computing platforms

1. Enterprise developers looking to cut costs of running their own IT infrastructure by porting existing apps or writing new apps. 
2. Web developers looking to build new applications who are interested in leveraging a high performance infrastructure without having to build their own.

As I pondered this list it occurred to me that neither of these groups is well served by Google App Engine.

Given the current economy, an attractive thing to enterprises will be reducing the operating costs of their current internal applications as well as eliminating significant capital expenditure on new applications. The promise of cloud computing is that they can get both. The cloud computing vendor manages the cloud so you no longer need the ongoing expense of your own IT staff to maintain servers. You also don't need to make significant up-front payments to buy servers and software if you can pay as you go on someone else's cloud instead. Google App Engine fails the test as a way to port existing applications because it is a proprietary application platform that is incompatible with pre-existing application platforms. This same incompatibility rears its head when you look at App Engine simply as a way for enterprises to do new development. App Engine is based on Python, which if you look at the State of the Computer Book Market 2008, part 4 -- The Languages is not a terribly popular programming language. In today's world, enterprise development still means Java or .NET development which means enterprises will favor a platform where they can reuse their existing skills and technology expertise. Google App Engine isn't it.

So how about Web developers? In my classification, I broke up Web developers who'd be interested in cloud computing into hobbyists (like myself when writing a Twitter search engine on Windows Azure) and professionals (like myself when working on the platform that powers Hotmail's recently launched social features). Hobbyists either don't spend money or spend relatively little so I discounted them as a target audience of interest. The professional Web developers interested in cloud computing would be those who are considering Server or Web hosting but have concerns about scaling up if their service gets successful. After all, it seems like every week you are either reading about scaling hurdles that startup developers have faced as their applications become successful whether it is Bret Taylor's recent post How FriendFeed uses MySQL to store schema-less data or Jeff Atwood's Deadlocked! which talks about how he had to learn more about SQL Server's locking strategy as StackOverflow.com became more popular. The fact that Google App Engine is limited to only Python meaning that it is unavailable to developers using WISC platforms and only a subset of developers using LAMP can participate on the platform. Furthermore, there are key limitations in the platform that make it infeasible to build a full scale application. For example, Bret Taylor mentions that a consequence of having a denormalized database they need to run a background "Cleaner" process which fixes up data references and makes their database consistence. The App Engine DataStore API requires applications to store data in a denormalized way but there is no facility to run background processes to clean up the data as FriendFeed and most other large scale services which use database sharding often do. According to a recent blog post the Google App Engine roadmap has been updated so at least this limitation will be addressed. Other limitations for Python developers are that they can't use all of their existing knowledge of Python libraries since it only supports a subset of Python libraries. Database developers may be relieved that a lot of database management tasks no longer exist but may be chagrined once they see the restrictions on queries they can perform and hear some of the horror stories about query performance. At the end of the day, it just didn't seem to me that there were many professional Web developers who would put up with all of this pain over just going with AWS or dedicated hosting.

That said, Google App Engine does address the long tail of developers which I guess is nothing to sneeze at. Maybe it will see some success from targeting the low end in the same way that AdSense targeted the long tail of advertisers and is now the powerhouse of search advertising. Maybe. I doubt it though.

Now Playing: Aerosmith - Livin' On the Edge

 

Earlier this morning I was reading a number of comments in response to a submission on reddit.com where I found out that despite being a regular visitor to the site there were multiple useful features I was completely unaware of. Here's a list of features I discovered the site has that I hadn't noticed even though I visit it multiple times a day

• Private user-to-user messaging feature including an inbox containing all responses to your comments.
• A social networking component which enables you to customize the site so you only see content from your friends.
• An option for bookmarking my favorite stories so I could come back to them later

These are all clearly useful features. In fact, some of them are features I'd have lobbied for if ever asked what features I'd like to see added to reddit even though they already existed. Considering that I'm a fairly savvy Web user and visit the site multiple times a day, it is problematic that I'm unaware of valuable features of the site which were the result of valuable effort from the developers at reddit.

This is a very commonplace occurrence in software development. As applications add features without wanting to clutter the interface, they begin to "hide" these features until it gets to the point where their users end up clamoring or pining for features that actually already exist in the application. A famous example of this comes from Jensen Harris' series of posts on the UI changes in Office 2007. There is rather informative post entitled New Rectangles to the Rescue? (Why the UI, Part 4) which contains the following excerpt

Contrary to the conventional wisdom of the naysayers, we weren't (and aren't) "out of ideas" for Office.  Customers weren't telling us that they didn't need new features--to the contrary, the list of requests is a mile long.  Every version we were putting our heart and soul into developing these new features, undergoing a rigorous process to determine which of the many areas we would invest in during a release, and then working hard to design, test, and ship those features.  The only problem was that people weren't finding the very features they asked us to add.

To address the issue above, the Office team effectively dedicated a release to making their existing features discoverable¹. This isn't the only example of a popular application dedicating a release to making features more discoverable instead of adding new features. The Facebook redesign of last year is another famous example of this which has lead to increased usage of the site.

A recent TechCrunch article, Facebook Photos Pulls Away From The Pack shows the effect of the redesign on the usage of the site

...
What accounts for Facebook’s advantage in the photo department? The biggest factor is simply that it is the default photo feature of the largest social network in the world. And of all the viral loops that Facebook benefits from, its Photos app might have the largest viral loop of all built into it. Whenever one of your friends tags a photo with your name, you get an email. This single feature turns a solitary chore—tagging and organizing photos—into a powerful form of communication that connects people through activities they’ve done in the past in an immediate, visual way. I would not be surprised if people click back through to Facebook from those photo notifications at a higher rate than from any other notification, including private messages.

But the tagging feature has been part of Facebook Photos for a long time. What happened in September to accelerate growth? That is when a Facebook redesign went into effect which added a Photos tab on everyone’s personal homepage.

The lesson here is that having a feature isn't enough, making sure your users can easily find and use the feature is just as important. In addition, sometimes the best thing to do for your product isn't to add new features but to make sure the existing features are giving users the best experience.

When you do find out that usage of a feature is low given it's usefulness and relevance to your user base, this is a good time to invest in an experimentation platform where you can perform A/B testing (aka split testing) and multivariate testing. There are a number of off-the-shelf tools for performing such experiments which enable you to test and validate potential redesigns today without unleashing potentially negatively impacting changes to your entire user base.

---

¹I believe the Office team shipped lots of new features as well in Office 2007, however the biggest change from an end user's perspective was the redesign not new features.

Now Playing: Metallica - Harvester of Sorrow

 

I often wonder whether the founders of Twitter think of the site as a social utility that helps keep people connected with the people they know and care about like Facebook or whether it is primarily another personal publishing platform like Blogger. How they view the service influences the features that are the added to the site and its evolution.

For example, take a simple feature like "friend suggestion". A site that views itself as a social utility would implement such a feature in a way that attempts to bring you together with people it thinks you know or who've implied they know you. A site that views itself as a personal publishing platform for would-be pundits and people interested in them will end up recommending the most popular users in a move that mirrors the Bloglines Top 100 or recommending people based on editorial choice instead of how they relate to you.

Now compare the results of Twitter's Suggested Users feature shown below 

with one of Mr. Tweet's various recommendation options

Twitter's suggestions for me include a grocery store, the microblog of an online shoe store CEO and a mommy blogger. On the other hand, Mr. Tweet has actually recommended people I have met or at least know professionally. As I go down the list of recommendations from Mr. Tweet and finally encounter people I don't know they are at least people who move in the same circles as me online. On the other hand Twitter's list contains a grab brag of celebrities and brands that have no direct connection to me.

Twitter is squandering an opportunity to grow their social graph in a way that deepens their users connections on the site and with the site. If I were in their shoes, I'd pick up Mr. Tweet in the same way they picked up Summize because the technology and feature set nicely complements the site and fills a hole in their user experience.

Now Playing: Metallica - Leper Messiah

 

There's some storm in a teacup around Facebook's terms of service which is in reality just another iteration of the freak-out-because-web-company-changed-their-terms-of-service that we see in the blogosphere every couple of months. For the most part this is a boring dance but there is an interesting issue around end user expectation around sharing content and ownership of their personal data underneath all the melodrama.

The point of interest is called out in Mark Zuckerburg's post On Facebook, People Own and Control Their Information where he writes

One of the questions about our new terms of use is whether Facebook can use this information forever. When a person shares something like a message with a friend, two copies of that information are created—one in the person's sent messages box and the other in their friend's inbox. Even if the person deactivates their account, their friend still has a copy of that message. We think this is the right way for Facebook to work, and it is consistent with how other services like email work. One of the reasons we updated our terms was to make this more clear.

The issue of what to do with content a user has shared when they decide to delete the content or attempt to revoke it is in an interesting policy issue for sites geared around people sharing content. When I've discussed this with peers in the industry I've heard two schools of thought. The first is that when you share something on the Web, it is out there forever and you have to deal with it. Once you post a blog post, it is indexed by search engines and polled by RSS readers and is then available in their caches even if you delete it. If you send an inappropriate email to your friends, you can't un-send it. This mirrors the real world where if I tell you a secret but it turns out you are a jerk I can't un-tell you the secret.

The other school of thought is that technology does actually give you the power to un-tell your secrets especially if various parties cooperate. There are ways to remove your content from search engine indexes. There are specifications that dictate how to mark an item as deleted from an RSS/Atom feed. If your workplace uses Outlook+Exchange you can actually recall an email message. And so on. In the case of Facebook, since the entire system is closed it is actually possible for them to respect a user's wishes and delete all of the content they've shared on the site including removing sent messages from people's inboxes.

I used to be a member of the second school of thought but I've finally switched over to agreeing that once you've shared something it's out there. The problem with the second school of thought is that it is disrespectful of the person(s) you've shared the content with. Looking back at the Outlook email recall feature, it actually doesn't delete a mail if the person has already read it. This is probably for technical reasons but it also has the side effect of not deleting a message from someone's inbox that they have read and filed away. After all, the person already knows what you don't want them to find out and Outlook has respected an important boundary by not allowing a sender to arbitrarily delete content from a recipient's inbox with no recourse on the part of the recipient. This is especially true when you consider that allowing the sender to have such power over recipients still does not address resharing (e.g. the person forwarding along your inappropriate mail, printing it or saving it to disk).

At the end of the day, many people would like to use technology to solve what is essentially a social problem instead of adjusting their behavior. The bottom line is that even though it is technically possible for Facebook to delete my private messages from your inbox when I decide to delete my account, it would be harmful to your user experience AND it doesn't buy me anything since you've already seen the content. The real solution is for me not to have sent any messages to you that I'll later regret in the first place.

Now Playing: Bush - Everything Zen

 

The New York Times has an article titled How Google Decides to Pull the Plug which talks about the rationale behind the rash of abandoned and cancelled projects that have come out of the Big G in recent months. The article contains the following interesting excerpts

GOOGLE recently set the blogosphere abuzz by announcing that it was pulling the plug on several products.

The victims included Lively, a virtual world that was Google’s answer to Second Life; Dodgeball, a cellphone service aimed at young bar-hoppers who wanted to let their friends know where they were hanging out; Catalog Search, which scanned paper product catalogs so they could be searched online; and Notebook, a simple tool that allowed people to take notes on Web sites they had visited.

Google also said it would stop actively developing Jaiku, a microblogging service similar to Twitter, and instead turn it over to its users as an open-source project they could tinker with as they wished.
…
All of the shuttered projects failed several of Google’s key tests for continued incubation: They were not especially popular with customers; they had difficulty attracting Google employees to develop them; they didn’t solve a big enough problem; or they failed to achieve internal performance targets known as “objectives and key results.”

You’d think that Google, a highly profitable engineer’s playground, would keep supporting quirky side projects as long as someone wanted to work on them. The company, which is best known to consumers for its search engine, is famous in business for promoting innovation by letting engineers devote 20 percent of their time to projects outside their main responsibilities.

But in this difficult economy, even Google is paying more attention to costs.
…
Lively, Google’s entry into three-dimensional virtual worlds, was publicly unveiled last July. Four months later, when the company decided to close it, only 10,000 people had logged into the service over the previous seven days. That was well below the targets set by Google’s quarterly project review process, and far behind Second Life from Linden Lab, which had about half a million users in a similar period.

“We didn’t see that passionate hockey-stick growth in the user base,” said Bradley Horowitz, Google’s vice president for product management. Management decided that the half-dozen people working on Lively could be more productive elsewhere.

It will be interesting to see what the long term effects of these changes in perspective will be on Google's culture around launching new products out of 20% time projects and the veneration of side projects at the Googleplex. One expected change is that employees will be more conservative around what 20% projects they choose to work on so that they don't end up wasting their time on the next Google Page Creator or Google Web Accelerator which is received with initial hype but quickly discontinued because it doesn't see "hockey stick growth in user base".

You can already see this happening somewhat by looking at how many side projects are being shipped as part of Gmail labs. Checking out the list of Gmail labs offerings I see over 30 big and small features that have been added to Gmail as side projects from various individuals and teams at Google. It seems on the surface that a lot of Google employees are betting on tying their side projects to a huge, successful product like Gmail which isn't in danger of being cancelled instead of working on new projects or helping out smaller projects like Dodgeball and Jaiku which eventually got cancelled due to lack of interest.

This expectation that a new Google product will need massive adoption to justify its investment or be cancelled within four months, as was the case with Google Lively, will be a significant dampener new product launches. Reading Paul Buchheit's post on the early days of Gmail I wonder how much time he'd have invested in the project if he was told that Google would cancel the project if it's user base growth wasn't competitive with market leaders like Yahoo! Mail and Hotmail's within four months.

I suspect that the part of Google's DNA which spurs innovation from within is being killed. Then again when you look at Google's long list of acquisitions you realize that a lot of their most successful projects outside of search including Google Maps, Blogger and YouTube were the results of acquisitions. So maybe this culture of internal innovation was already on the way out and the current economic downturn has merely sealed its fate.

Now Playing: Metallica - Fade To Black