It's been three years now and we're still going strong. Every day I'm amazed at how much I've learned, and yet somewhat apprehensive about the lessons I haven’t gotten to yet. Some of the times have been rough. Really rough. Yet somehow, everything always seems to work out and things get better and better. Year four looks to start out strong, and I’m excited to wake up tomorrow and get it started.

10/4/2007 10:17:29 PM (Pacific Standard Time, UTC-08:00)      Comments [1]  

We recently launched PuckLink, a social network designed for recreational hockey players. After playing for a few years in the northwest, it seemed clear that people needed a better way to manage and coordinate teams, games, and practices.

You can check it out at http://www.pucklink.com. If you know anyone who plays hockey, please let them know!

9/4/2007 11:47:19 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

For those who don't get why this is funny, you should know that AdCenter is Microsoft's competitor to Google's AdSense.

7/11/2007 12:24:50 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

I had an interesting meeting with my old friend Mike Culver this morning. Mike and I worked together back at Microsoft when he ran the evangelism efforts for the mobile developer platform and I was the .NET Compact Framework product manager.

Early in the conversation, Mike asked me if I was familiar with Amazon’s developer platform. Years ago I had dug a bit into their commerce Web services, so I figured I could bluff my way through the exchange. After all, SharpLogic is The Developer Marketing Company, right?

Wrong. Mike now works as a developer evangelist at Amazon. He knows when I don’t know.

Sure enough, Amazon’s platform has grown way beyond what I would have expected. Among the various services available, the two that became immediately intriguing were the Simple Storage Service (aka S3) and the Elastic Compute Cloud (aka EC2).

In a nutshell, you can use S3 to cheaply store and serve a virtually limitless amount of data and EC2 provides virtualized servers (Linux-only for the foreseeable future). The neat thing about these is that you can scale up and down as much as you want and you only pay for what you use. Each EC2 node, for example, costs $.10 per hour. If you only use an hour a month, you only get charged $.10 a month. If you happen to have a huge load for 24 hours, you can continue to add more and more nodes, and then turn them off when the load is gone. You can even upload your own OS image. Amazing.

Microsoft and Google have some interesting offerings in a similar vein, but I haven’t seen anything public to meet this head-on yet, so Amazon is out to a huge advantage. I’m excited to see where this goes.

5/30/2007 3:46:52 PM (Pacific Standard Time, UTC-08:00)      Comments [0]  

I find that most upstream project errors occur due to simple misunderstandings. Although I always try to ask all the relevant questions early on, there are almost always gaps in what I’m really trying to learn, and sometimes there are subtleties in terminology that mean very different things when being translated from business requirements into technical specifications.

Last week, we had a project extended slightly to support an additional locale. The engineer responsible for the project gave me two options: one simple (but inelegant) and the other sophisticated (but time consuming). I asked the client if they had a preference between the two, but rather than explaining how this impacted the business aspects, I pretty much laid it out as “hack vs elegant”. The client opted for the more elegant approach, which we began.

I took a walk to ship something from the UPS store. On my way back to the office, a car pulled up next to me and a woman asked “How can I get out of Redmond?”

Being the helpful citizen, I replied, “Pick a road and don’t make any turns.”

She smiled—patiently—and asked me how to get to SR-520, the nearest highway. After all, this was the question she really wanted answered. She was two blocks away, so I obliged and gave her the info she really wanted. I’m pretty sure that worked out fine.

Anyway, I rushed back to the office and called the client again. This time, rather than asking the “hack vs elegant” solution, I explained how the decision we were making now would impact the way we would extend the project in the future, and asked the client where they saw the project evolving to. As it turned out, the client had upcoming features I hadn’t accounted for, and the “hack” approach was actually the more elegant option because of the feature requests we would receive once we finished off the current round.

The moral is simple: ask the question you really want answered. It makes life a lot easier down the road.

5/1/2007 10:02:13 PM (Pacific Standard Time, UTC-08:00)      Comments [0]  

A lot of companies I call often have a message that says “We are experiencing higher-than-normal call volumes” when I call their customer service line, which I assume is to set expectations that they might leave me on hold for a long time. In most cases, I’m able to get to a representative within 5-10 minutes, which is kind of what I expect under normal circumstances.

Anyway, I happened to be up around 4AM this morning (Easter Sunday in Boston) when I noticed I had a mail from Expedia saying that I needed to call them because an itinerary for an upcoming flight (several months in the future) had changed. To my surprise, I received the “high call volume” message, even though someone picked up immediately after the message was finished. Unless one call is “higher-than-normal”, I suspect that Expedia leaves up this message permanently.

This practice is known as "sandbagging" and parallels the use of sandbags to weigh down hot air balloons. If a balloon needs to rise rapidly, the sandbags can be easily thrown overboard, resulting in a reduction of weight that gives a temporary boost to the balloon’s ability to rise. In this case, Expedia wants me to believe that it will take a long time to get around to my call so I won't be unhappy if it takes a long time. In the event that they get to my call faster than expected, I probably won't be unhappy since it's to my benefit.

A lot of businesses sandbag in their own ways. Sometimes it’s important to pad a schedule for unexpected issues, and sometimes it’s useful to smooth revenue for the perception of predictable growth. Individuals are the same way in both business and personal relationships. However, once you get a reputation for being a perpetual sandbagger, you begin to lose credibility, and that’s never a good thing. We all know someone who is perpetually "slammed" or "doomed" with work

Last week, for example, I needed to book a last minute flight from Toronto to Seattle (“last minute” as in “in a cab on the way to the airport”), so I called American Express travel (and likely paid a hefty premium) because I knew that Expedia always had “higher than normal” call volume and didn’t know if I would be able to get through in time. Ironically, I probably wouldn’t have had any problem getting through to Expedia, but I knew I couldn’t trust the message to indicate whether the call volume was actually high or not, and five versus thirty minutes would make a huge difference. Although this is probably a rare case, it’s one where perpetual sandbagging can come back to hurt business credibility. Then again, Expedia is run by very competent people, so it’s very likely that they have weighed the costs of one-off business losses like this versus the customer satisfaction benefit of being able to exceed customer support expectations. After all, it’s not like I don’t use Expedia—I just don’t use them when I need high quality support, which is actually what they want me to believe.

4/8/2007 1:06:24 AM (Pacific Standard Time, UTC-08:00)      Comments [1]  

This is awesome. I haven't really played much with Expression Web, but I've done a ton of stuff with Expression Blend and it's a great tool.

4/3/2007 8:05:27 PM (Pacific Standard Time, UTC-08:00)      Comments [0]  

Dan posted the casting results for the upcoming Microsoft blogger movie. Check it out.

In hindsight, I wish I pushed harder for my own casting. It would be nice if people had actually heard of the guy who was going to be playing me.

2/27/2007 8:17:59 PM (Pacific Standard Time, UTC-08:00)      Comments [2]