First Impressions, Second Impressions

Ok, I'm not aiming specifically at the quality or related issues of the Moto Q or Treo 700w here. But this Amazon review of the Q is just brilliant: http://www.amazon.com/gp/cdp/member-reviews/A10U3Z35FCPXF2/

Synopsis (if you haven't read it yet or are too lazy to click through):

1. Smartphone-savvy customer is delighted to begin working with his brand new Motorola Q.
2. Customer discovers some minor issues and remains enthusiastic and forgiving.
3. Customer has multiple hardware failures. Service rep suggests an alternate device with a better quality track record (in the opinion/experience of the rep).
4. Customer buys this alternate device and regrets giving the 5-star review to the Q in the first place.

Footnote: This all takes place in a week, and remember this reviewer seems to be a sophisticated PDA/phone user.

Question: When (Apple) did firms pushing the "high-end" wannabe-Lexus products (Apple) start acting like used car salesmen (Apple) hyping something shiny (Apple) that barely drives off the lot (Apple) with the engine still running?

Someone set me straight here ... meanwhile, I guess this is why I drive a Honda and build my own whitebox PCs...

Relational Databases: What are They Good For?

I'll answer the question: they're typically good for a whole lot, provided a whole lot looks something like:

• Extreme concurrency support (if handled right)
• Solid transaction support, with well-known deterministic tradeoffs agains concurrency
• Deterministic (in both time and output), standardized (mostly) and accessible query capability
• Proven logging, failover, and recovery mechanisms
• Standardized management and operations tools
• Exposure of data to standard, existing reporting and OLAP tools
• Declarative management
• Declarative data cleanliness constraints
• And a few other things
  

Now, nowhere in that list does it say "great data structure for every problem domain" -- or even "great data structure for many problem domains." In fact, the relational model is inherently a good structure for a few domains, but by no means a large number.

And yet somewhere along the way, in the last 20 years or so, it's become a not-entirely-embarrassing-and-career-limiting-move to design a software system by initially modelling entities in a relational model, then slapping a wrapper above the SQL (maybe even auto-generated), tossing a UI on there, and declaring "Mission Accomplished." Wait! Where's the "business layer"? Well, that's where things start to go off track. Actually it's usually above the DB wrapper piece and below the UI -- but more importantly it's usually almost empty in the beginning, since the designer has an entity model that is tightly coupled to the current flavor of business rules. The business layer becomes a real monster ... er I mean tier ... later, when each case or change that isn't supported by the data schema earns a hack-around in the business layer. And at the end of the day all of these systems end up looking and acting the same way: like the 3-tier DB apps they are.

What's wrong with that? The fact that the apps end up expressing this architecture more strongly than they express solutions to their problem domain. These apps feel like fields and records -- they don't feel like what they actually are (e.g. a cell phone provisioning app, a flight management app, etc.) So they're mediocre and they're disliked by their users, disliked by their maintainers... they're "good enough" ... "until we have a chance to do it right."

For most apps, a database is a particular way to persist data, with some handy aspects, that's all. Don't design like it's anything else! Design like you're building a video game, like the experience is everything and only the user interaction needs to be right (and 100% right). The reality of business apps may be dirtier in the details (not to mention you'll rarely have the resources to make your UX dreams come true), but that's the point: if you're smart you can keep it in the details. Which means designing a whole application not just a database.

Remember "Disintermediation"

That was a hot word for the way some online businesses were reshaping value chains in the late 90s by eliminating various links. One might think that arbitrage and free markets being what they are, all of the legitimate disintermediation opportunities were exploited years ago.

But here's a new one -- well, it's not new anymore, but it's a lot more recent. Anyone who has ever bought a pair of eyeglasses retail can't help but wonder what kind of scam is being perpetrated. In an era of $19 MP3 players and $300 PCs, we have $250 for an eyeglass frame that just screams "Made in China, $20 per dozen" Not to mention that in many developing nations, people do buy eyeglasses, and the $250 pricepoint would be unimaginable. Then you pay $40+ for lenses (which are pre "ground" and come out of an envelope), and extra for all sorts of protective magical coatings.

About a year ago I googled for discount eyeglasses, thinking that surely out there on the web someone is importing these $1 frames in bulk and would sell them to me for a modest 1000% markup of $10. No luck. Lots of bogus sites, and the legitimate ones were just selling the same "designer" frames at the same price ($1 manufacturing + $5 licensing + $244 American sucker tax = $250)

Fast forward to today: Google for eyeglasses, and you find a dozen sites selling complete glasses (i.e. frames + prescription lenses) online for anywhere from $15 to $50. I tried a pair from a San Rafael company called Zenni Optical (a.k.a. 19dollareyeglasses.com) because at that price, really what was there to lose? I had the glasses in a week, they look great, the optics are fabulous, done. Price including shipping: $28. These guys rock out!

The only mystery left is: how can a business make any money selling a pair of glasses at, say, $25. Unlike the commodity MP3 players, these glasses do need a little bit of handling and custom work (cutting the lenses, inserting into frames, packing, etc.) The fast shipping and one-off ordering suggests that the custom work is being done in the U.S., not overseas. Let's say it takes 20 minutes to process a pair, and there is $20 of margin in the $25 glasses. That's $60/hour. Which isn't bad if you've got a couple of employees, low rent, and your production pipeline is full. But if the pipeline has some slack, or you have a manager in there somewhere or any kind of real estate ... that's brutal! Even Wal-Mart's absolute cheapest non-branded glasses were about $65 (frames + lenses) last time I checked...

ByRef moreDetails As String

Quiet down, you'll get the joke when you follow the links.

My last post talks about what's not there as far as developing for the Palm. Jamie Flournoy, who has done a ton of rocking contract work for Skip on our mobile clients, has written a post discussing the solution the we did choose for building a new Palm/Treo client.

Even better, he's going to be contributing to the community a test framework he built, and some hard numbers that can be used to look at relative productivity for different tools. Thanks, Jamie!

Waiting for Godot ... er, Cobalt

At Skip, we're creating a native (well, 68K, so native vis-a-vis Java) client for the Palm. In particular, we're targeting the many Palm Treo smartphone users, who deserve a more robust Skip experience than Java has been able to deliver.

In the process of building this client, we've been stunned by the huge gaping hole that is the Palm high-level app development platform.

Since ours is a high-level business/productivity type app, since the client is not complex, and since we support many platforms, some sort of RAD tool or at least high-level API is ideal for client development.

The amazing thing is that the space is a gaping void, where only a handful of tiny ISVs with proprietary tools play.

IBM hasn't updated its Java implementation for Palm in several years ... it's not great, not free, and has no roadmap into the future. At the other end of the spectrum, PalmOS has a broad C API, but this is no high-productivity environment (it's more like C for Win 3.1). Not to mention that using many third-party C libraries requires assembly hacking and linker foo, not ./configure and make.

Adobe could push the Build button and release a Flash player for the Treo that would instantly become the high-level environment of choice for 21st-century connected apps. And the great UI possibilities would be a bonus!

The lack of a top-notch development system is even more mysterious given the large community of Treo users and thriving (by PDA/phone standards) ISV app ecosystem. In other words, the Palm Treo area is one of the most successful and least risky places to invest in infrastructure, with the highest potential return.

Presumably this whole situation stems from the prolonged wait for imaginary Cobalt devices. That's going to make things all better. Real soon now.