Force Feeding You Change

Google loves to just drop new features in your lap. I remember when I first noticed Google Talk; I came back to my computer and Graham had dropped me a line, "yo fezzik, whats shakin bro?" (of course, Eric was the second person to send me a chat). I was all "WTF is this? Get out of my inbox!" But I got over it.

It reminds me of the way Blizzard would work their betas. For the Warcraft 3 expansion beta, when they added a new unit, they would make that unit overpowered so that everyone would use it (When they added "fragmentation shards" to the mortar teams, they made the effects so loud and big that they were impossible to ignore). That way Blizzard could see how people reacted to it, how they used it, etc. They would use that data to find the right balance.

That's just like what Google has done with Talk and Buzz. They just throw it right at you, in your face, in Gmail. You have no choice but to deal with it (yeah, sure, you can disable them both, but how long did it take you to find that little link?). And so now everyone is talking about Buzz, using Buzz, and Google can use all this feedback to flesh it out properly. Nicely done, Google.

The Balance Between Safety and Speed; or, Does the Turtle Really Beat the Rabbit?

Eric and I argue about programming all the time and about every little thing, but we're really just arguing about one thing. I value safety, and he values speed. Let me elaborate.

The safety I'm talking about is making sure my code works right. I'm for strong typing because it can help find errors at compile time. I believe that databases have to enforce their constraints as best they can even if you're the only client. I prefer centralized version control (CVCS) over distributed version control (DVCS) because the restrictions CVCS enforces promote healthy branching and code. I believe in continuous integration, including full unit and integration tests.

The speed Eric talks about is being able to write "5.times.per.day" in Ruby and have it just work the way you expect. Eric loves git because he's able to get input seamlessly from developers around the world and easily integrate new code. And he loves easily discoverable features of his languages of choice.

Most of the time, the programming context determines the value of the two assets. Building a mission-critical app that handles financial data? Safety rules the day. Building a site to determine if it is Christmas or not? Speed please.

Programmer personality also is a significant factor. I know I make mistakes, so I prefer to use tools that prevent/detect said mistakes. I also know that others might use my code at some point, and as anyone who has ever worked with someone else knows, other people are dumb.

The reason I just started writing about this was because I had to change a "Thread.Sleep" call in one of my integration tests from 2 seconds to 5 seconds. To make this change and formally deploy the code to my project's development environment, I had to run the code through the entire 12 minute build process. And that's AFTER running the unit tests locally (5 more minutes). It would've been so nice to circumvent the whole process. And I wanted so much to do just that! But I held fast to my rules, and now I know the published package built from that build is ready to be released to QA.

Abstract This!

I just recently installed Mozilla's Prism, and I gotta say, I love it. I have one set up for GMail, Campfire, and Google Docs (GDocs?), and those windows are super snappy. I do miss my Better Gmail extension for Firefox, but its no big deal.

I only have two big issues with Prism:

• I cannot customize the download location.
• All Prism instances run under the same process.

The first is mostly trivial; I download all my files to c:\downloads instead of the desktop, so that's just a copy/paste away. The second issue is more important. Google Chrome created the idea of browser process isolation; if one tab locks up or crashes, it does not bring down the other tabs.

That feature is awesome.

Eric disagrees with me that Prism "needs" process isolation; he thinks that the beauty of Prism is the UI, aesthetics, and speed. Hey look, I have my GMail "application" open, it's just one application, and look how fast and clean it is!

Well, process isolation is a vital part of that abstraction. When Excel crashes, it does not bring down Firefox with it. Likewise, when Prism-GMail crashes, it should not bring down Prism-Campfire with it. If Prism's goal is to abstract websites to be desktop apps, then each one needs to be isolated into its own process.