Christopher on Gmail: The Review

I guess you can call me Charlie, because I’ve found one of Willy Wonka’s Golden Tickets – a GMail invite, that is. I set up my account about 10 days ago and have been playing with it ever since. I’m fairly impressed, but I expected to be. Google does not produce garbage. For the benefit of those who do not have a GMail account but are curious about the service, I’ll do a mini-review here.

I Feel Pretty…

First off, the interface is nice – minimalist, clean and effective, just like the main Google page. The first thing one notices about the GMail interface is that instead of presenting a list of eMails, GMail groups entire eMail threads together under one subject line – that is to say, you only see the subject line in your Inbox one time, instead of seeing it one times for every message sent with that subject line. In my opinion, this alone is sufficiently compelling to justify a move to GMail from whatever web mail you might be using now. If the benefit of threaded eMail is not clear to you, let me put it this way: you’ll never again feel dread when a client or colleague asks you "Did you get my last eMail about that that?".

Got Ads, Shown Live If You Want Them

Next you have the targeted advertising. This is upsetting a number of people for some reason, but I love it, especially because a lot of my eMail consists of consulting with colleagues on programming and tool matters. It never hurts to have a fast link to relevant items at hand. Notice the ads along the right-hand side of the page in Figure 2; not only are they context-appropriate to the current eMail message, they are unobtrusive enough to keep me happy, all tucked away off to the side like that.

Bells & Whistles

One of the better features is the keyboard shortcuts. I defy anyone to think of anything they might want to do with an eMail message that cannot be done with GMail’s keyboard shortcuts. Compose message, Search, Reply, Forward, Archive, Next Message, Previous Message – iit’s all in there. Having these keyboard shortcuts will go a long way for some people – we all know that some users have a hard time using the mouse. Including these shortcuts takes GMail one step closer to being a "real" eMail application than other web mails services currently are.

Go, Speed Racer, Go!

For the those who complain of the lag inherent in doing anything over the web, let me tell you – GMail is pretty snappy. I have cable internet, so my connection is snappy in general, but the web mail offered by Hotmail and Yahoo! have always seemed sluggish to me.

My, What a Big Inbox You Have!

Now, on to storage. It is no secret that GMail has allocated an unprecedented 1GB of storage to each GMail user, the idea being that one should never have to delete an eMail. In truth, Google does not want us to delete eMail because it wants to analyze the spam we get, so it can offer filtering services in the future (it is worth nothing that Microsoft and other industry notables are working on the spam problem as well. Whoever comes up with a good solution first will have a huge foothold in a lucrative market – who DOESN’T want to filter out spam?), but whatever the motivation is, it is nice to not have to worry about butting up against some dinky size limitation.

This Is Not A Conspiracy

The paranoid among you can rest easy – GMail does indeed allow you to delete eMails, even if you don’t need to – you can send an eMail to the Trash, then select the ‘Delete Forever’ action, and *poof* the message is gone. It is interesting to note that there is no keyboard shortcut for ‘Delete Message’.

And the Winner Is…

…the users! There are a ton of free web mail providers out there – we’ve all got more than we need. That said, the threading, the 1GB of storage, the easy-to-use interface and even easier-to-use keyboard shortcuts make the switch to GMail make sense. If ever there were a better mousetrap, this is it. Also, by using GMail you are helping Google to fight spam. And who wouldn’t want to fight spam?

More Feedback on The 5 Pitfalls

Regarding The 5 Pitfalls of Estimating a Software Project, Jonathan writes in about an estimate his manager asked him for:

His first comment was that he had never seen an estimate given in hours. I explained to him that I didn’t like to give dates because of unexpected company meetings, sickness, etc. I don’t think this ever occurred to him. His second comment was that my estimate was too large and that he would have to “massage the numbers” so that the executives wouldn’t be upset. I was absolutely furious. What’s the point of even asking me if you’re not going to listen to my answer?

Sounds like I should have included a sixth item – not listening to your developers. But I think that probably falls under the heading of “allowing non-technical staffers to give estimates”. After all, once you override someone else’s estimate, the new numbers that you give the client are no longer the other guy’s numbers – they’re yours.

I’m getting a lot of great eMail feedback on the 5 Pitfalls, but not much in the discussion forum. Everyone feel free to drop a comment in there about any item in this blog – for that matter, feel free to start new topics to discuss.

Feedback on the 5 Pitfalls

Richard Caetano over at Strongly Typed made a great comment related to my 5 Pitfalls of Estimating a Software Project item:

“An off-the-wall thought: When I’m able to pull it off I do a project/time estimate as the inverse. I ask the customer how much time I have…then figure out what I can do in that amount of time. In a way a time estimate is a requirement. What good is a product if it can be delivered on time (which may be at arbitrary length) but not at an *applicable* time.”

Richard brings up an interesting point – sometimes you get a project that is only useful to the client if it can be implemented by a certain date. I often had to do the kind of inverse estimating that Richard refers to when I was building variable compensation systems; those Fortune 500 companies do their compensation processing on a certain schedule, and if I couldn’t deliver certain features by certain dates, the value of those features dropped to 0 until the following year! These days, most of my consulting work falls into the category of "things the client wants to do as soon as I can build a tool to do it with", but that is not going to be the case with everyone and it is good to bear in mind that sometimes you have to back in to your estimates.

Now that I’m thinking about it, backing into an estimate is also a great help in managing expectations. Once you present an estimate containing x number of features, if the client later has to change the due date for some reason, they won’t always understand when you come back and tell them that given the new date you can only deliver x – y features. They won’t always understand why you can’t just “work faster” and deliver the original feature set – they’re experts in their own businesses, not in the very unique (and sometimes strange) rules governing software development. Some might even be taken aback and think you are punishing them for giving you less time to do the project. It sounds outrageous, but it does happen.

Better to present an estimate with fewer features that you KNOW you can implement in the time allotted, if date constraints exist prior to your taking on the project.

Site Changes here at

As everyone who visits my site – yes, I mean both of you – can tell, I’ve been doing some cleaning up. I’m hoping the revamped is cleaner, more readable, and more interesting than the previous incarnation. The big changes are :

  • Condensing the site from about 20 pages to 5 more focused pages
  • Changing the overall look
  • Adding a weblog
  • Adding a discussion forum

There used to be a Projects page, which will be making a return as soon as I have enough screenshots to justify it. Who wants to read about the apps I’ve written when you can see them instead?

Christopher on Eric on Ries and Trout

Eric Sink has been doing something very cool for the past few days: he’s posting an opinion piece each day about one chapter of the Al Ries & Jack Trout classic, The 22 Immutable Laws of Marketing. As anyone who knows me can attest, this is one of my favorite books.

Anyway, Eric hit a sour note with me today. 😛 I feel compelled to razz him a little bit in response to his assertion that:

“We underestimate the value of mindshare when we try to change the minds of people. Ries and Trout say that "The single most wasteful thing you can do in marketing is to change a mind." I would love to know how much it will eventually cost to convince the world’s VB6 programmers to move to VB.NET. The audacity of this move is simply amazing. For any other company in the history of the earth, it would be suicide to try and change the minds of several million of your own customers.”

Now, I won’t challenge the premise that the industry often underestimates the value of mindshare. But using MS as an example just doesn’t fly.

No other company in the history of the Earth has ever had so much control over the environment in which customers use the company’s product as MS has right now, and that makes all the difference. Sure, the transition from VB6 to VB.NE will be expensive – but the end result is a lock; given sufficient time, most VB6 programmers WILL end up using VB.NET. The issue is not so much one of cost as it is one of value; however much it will eventually cost to force the transition, MS must think it will be worth it.

My point is that MS is not a good example to illustrate underestimating the value of mindshare because the consequences of that underestimation are miniscule for them. A company that attempted such a radical shift with the prospect of severe consequences might have been a better example.

Suppose (for example) that Pacific Bell tried to force all their residential customers to abandon their landlines and go cellular. Would they be guaranteed to retain all or most of their customers, even if they were handing out free phones? Probably not. Cellular service is largely undifferentiated between providers (they all suck equally), so rather than getting any kind of lock-in, Pacific Bell would lose a lot of customers.

But when you are a VB6 programmer who is largely dependant upon Microsoft’s operating system and IDE to do your work, who else can you turn to in the "operating systems and development tools for creating and deploying VB6 programs" market for the gear you need to continue being a VB6 programmer once there are no more flavors of Windows or Visual Studio that support VB6? I can’t think of anyone. Can you, Eric? 😉