I spent an hour this morning trying to figure out why a cohort here at 3tera couldn’t access our Google Analytics account.
Eventually I deleted him and restarted the whole process only to realize as I did so that I’d used a different email address for him
in adwords. Problem solved.
However, there’s still the interesting question of why the email addresses have to be the same between two such loosely coupled systems. It’s not noted anywhere on the site. There’s no technical reason for that constraint. It’s just a business or engineering decision that was made along the way.
Such constraints are common, of course. As another example, have you ever tried upgrading Windows Media Center Edition to XP Pro? Again, there’s no technical reason, but that upgrade path simply isn’t allowed. The only allowed upgrade is to Vista, and unfortunately for the shop I returned my new laptop to I ran afoul of that rule months before Vista was released.
Why do such rules exist? I’ve encountered a couple sources. First, developers and product managers feel they know how their
product should operate. They’re fanatically dogmatic about the use cases for the system and feel comfortable with enforcing what they think of as best-practices. The second source is a desire to cause customers to behave in a way that’s profitable to the vendor. Nuff said about that.
If you’re at all creative, then for almost any interesting task you can usually come up with more than a few practical ways to get it done. After all, just think about how many ways you’ve used a hammer or screwdriver that the manfacturer probably never considered. Have you ever considered the impact on the manufacturer. How should the engineers designing your tools prepare their wares for your unpredictable usage. How would you react if your hammer actually prevented you from crushing walnuts.
Decisions about where to limit users’ freedoms are a regular point of heated discussion between any good product management team and their enginners. That’s certianly true of our engineering staff and myself. I’m a firm beliver in building tools instead of rules and dislike restricting options for users unless there’s an exceptional benefit. Sometimes, of course, that benefit is simply that the system can be built. Engineers, on the other hand want to limit the number of permutations they need to support. Too much freedom bloats the QA plan. More often, though, they feel there’s a “right way” to do something and want to enforce it.
Part of my bias toward building tools comes from being a geek. Like all geeks, I love finding new ways to use gadgets. There’s a serious aspect to this bias too though. After many years of experience building systems sufficiently advanced that they change user behavior I’ve learned that predicting use cases can be dangerous. Imagine trying to map use cases for traditional auctions onto the development of eBay for instance. It would constrict users so much they might not use the system at all. When I was a product manager for one of the first laptops, this was exactly what happened – we patterned our use cases on desktops. Eventually I got rid of my desktop and worked with just a laptop (pre 1990) and I learned why users weren’t buying.
I’m writing about this today, because I just learned about the first case of a user losing a volume on an AppLogic grid.
The customer has a virtual private server with one of our partners and the grid operator decided to remove some servers for maintenance. Ordinarily, if you follow procedures, this doesn’t result in any loss of data. In this case, unfortunately, the operator circumvented the procedures and the system operated as a tool. After warning about potential lost volumes, it allowed the operator to proceed with removing several servers at once.
Our engineers stepped in to help and it looks like only a swap volume was lost – no real data. None the less, it raises the question of whether allowing the operator that freedom was the right behavior for the system. I’m comfortable that alerting the operator was sufficient, but I’ll definitely be thinking about this instance the next time the subject of rules versus tools comes up.