As discussed in an earlier post I’m embarked on a slow but presumably irreversible journey from “thick” apps to thin ones, from desktop to multiple clients to cloud.

Part of the lure is that most of the software, most of the time, is kind of “nifty”: it’s satisfying, pleasurable, fun to use in a way that I think lies at the heart of successful software.  It feels right.

Google software mostly fits into this category.  I like gmail a lot, I like the rest of the suite.  I haven’t moved over from Office to Google Apps in any major way yet, but it could happen.

But Google doesn’t act like the kind of software company I used to work for.  If something goes wrong, they don’t necessarily man up and they don’t necessarily fix it.

Take my Google Chat voice/video plugin.  I hadn’t used it in a week or so, and when I went to make a call from Chat I got a notice that the plugin needed to be installed.  “That’s funny, it’s already installed,” I said, but went to the screen and pushed the button to install anyhow.  Nothing happened.  I can’t make a call and I can’t re-install.

I find getting to Help in google software to be very problematic, but I found some kind of help search screen somewhere behind my profile photo and searched for help on this topic.  Nothing.

I then do what I do nowadays with most cloud software, Google-d the  broad we for it.  Found some threads, but nothing official.

Finally I found a reference to a “known issues” notice in Google help (why it wasn’t discoverable by search I daren’t ask the search king) and find out that this plugin problem is a known problem and Google is working “hard” to resolve it.

Now I know that Google doesn’t always live up to their “do no evil” stuff, but telling me that my help query was, in effect, “very important to us” was a nasty reminder that Google’s main effort here was to keep disruption of their operations by us needy users to a minimum.

All very American-business-as-usual-in-the-teens, but with a wrinkle: a cloud company has no main number to call, no Vice President of Customer Service to write.  I can only step up the game, as I’m doing now, by complaining about them online.

I wish they were more accountable.

Your thoughts?

I look to Tom Lang, all-star CTO at our video advertising company Videology Group, for insights into digital advertising technology, Big Data, and cloud, because he worries about them every day and, unlike many, worries constructively by finding resources that will keep Videology out in front.

When I asked him for background about NoSQL/NewSQL, he turned me on to The NoSQL Tapes site, which is collection of roughly hour-long video interviews with the rock stars of the NoSQL movement.

I’ll admit it’s an effort in today’s information-snacking world to pay attention to anything for an hour, but even in smaller snacks it’s worth it.  What a great site to find out more background on NoSQL.

As it turns out, Jerome LeCat from Scality is one of the sponsors (or THE sponsor?) of NoSQLTapes.  Jerome (Twitter @jlecat) is a brilliant guy well worth listening to in his own right.

NoSQLTapes was a terrific idea.  I would welcome the same in other emerging technology areas.

Back in October I posted about the virtues of SQL and asked the question: what will replace it in a NoSQL/NewSQL hybrid world?

Don’t get me wrong: I dislike SQL as a programming language; I think it’s an awful kludge, and something inside me cringes every time I use it.  (Although, to be fair to SQL, I kind of feel that way about all the functional programming languages I’ve ever used: Prolog, (functional) LISP.  Functional programming bugs me the same way having to wait for the waiter to bring water bugs me when I’m thirsty and I can see the pitcher of water eight feet away at the waitstaff podium… but we disgress.)

But SQL has the virtue of separating the details of data storage and retrieval from the details of application logic, and we badly need something like that going forward.

As it happens, the relational paradigm itself is under attack from NoSQL approaches (or it should be; I never really liked the relational paradigm much, either; it has a heck of a time with anything “complex” (join-y, recursive-y, set-y), and doesn’t do such a great job on things that are simple, either.  But we digres…)

So maybe we can kill two birds with one stone: advance beyond the relational paradigm and start an API to data (even if not yet a language) that is agnostic about the structured-ness of the underlying data.

I guess I’m going to out completely here, and say that I also hate XML sublanguages by and large.  They are bloated, difficult to compute on, and PL/1-ish.  With exceptions, perhaps.

But something on the order of abstraction of RDF sounds like the “new relational” to me.  Even after the rise and fall of the “triples empire” some years ago.  A simple atomic relationship binding two entities together seems like a logical place to start.

As usual, I’m way out of my depth here.  I hope someone who actually knows something about these matters will step in.  But I do feel obliged to bring the matter up.

Your thoughts?

As I said in an article I wrote for the Cutter IT Journal in May, if I had lost my PC’s connection to the Internet even as late as 1999 or 2000 it would have been an inconvenience, but if I lost it today the thing would be close to a brick as far as its use for me.

Times have changed.

I’ve migrated, slowly but steadily, from thick-client PC-based applications to cloud-based applications that run on my PC, my Android phone, and my iPad.

I still love the rich interaction and aptness of the interaction in a good thick app.  Even today the JavaScript etc. interactive tricks don’t hold a candle to a good local interaction with both UI/UX and business logic right nearby rather than a variable-latency roundtrip away.

But today I prize the ability to run on all my clients more than I prize the excellence of the interaction on any of them.  And that factor — the need for sync — has driven me inexorably toward cloud-based apps.

Some of which are quite good.  Don’t get me wrong.  Apps like ToodleDo and Zite and even some of the Twitter client stuff are getting there.  But I’m using them on one platform because I want to access them on all.

Thoughts on your app migration towards the cloud?

I hate coining buzzwords.  And maybe I didn’t even coin this one.  But we need some phrase to describe the following problem:

Data now comes in two processable flavors: structured and unstructured.  And stacks now exist for processing either flavor.  But each world is undergoing transformation.  And how the two worlds will be combined is up in the air.

Unstructured data: whether or not the Hadoop ecosystem is The Answer, there is vigorous experimentation with how to work with massive amounts and velocities of unstructured data, and there are some emerging norms.  Other NoSQL approaches remain as alternatives, and there will probably be use cases for almost all of them.  We are not even near the end of the beginning when it comes to defining how unstructured data systems will interface with applications (where is the NoSQL SQL?), and we are IMHO still at the very beginning of understanding what storage systems are optimized for these workloads.

Structured data: with NewSQL databases, it is clear how to interface them with applications but far from clear how they work with storage systems, particularly SSD-based storage systems.  Jury is out as well on how to multiplex the different databases in a use case.

I call of this “data management infrastructure”, and it seems to me like an emerging big design problem.

Thoughts?  Who’s working on this?  Where should we invest?

I blogged here last week about my “big wind/capable team” heuristic for picking startup investments.  Today I’d like to go into a bit more detail about the “big wind” part.

A Big Wind is a transformation of a large customer spend from one category to another.  It’s almost the same thing as Geoffrey Moore’s idea of a “tornado”, which is a phase in a market when the (relatively) vast Early Majority group decides to adopt a new approach.  Moving suddenly from “show me” to “must have”, the Early Majority creates a “tornado” of demand.  Examples: the PC “revolution”, networked storage systems, scale-out servers.

Smartphones are in the midst of a tornado-like Big Wind.  Sweeping away RIM and Nokia and perhaps Microsoft.  Sweeping in Apple and Google.

Maybe tornadoes are the only kind of Big Wind that exists, but in any case, most of the examples I can think of are tornadoes.  Maybe the ERP implementation at the end of the last century was a Big Wind without being a tornado.  It was driven in large part by Y2K FUD, not by a transformation of the Early Majority to a new approach.

Great example of not a Big Wind: healthcare IT so far.  Big market, but no transformation of spend (yet).  Right now only early adopters are embracing end-to-end IT for their health businesses.  The early majority is hanging back, saying “show me.”  It may tip.

Your thoughts?

Watching the Euro community grapple with and fail (or so it seems) under the onslaught of treaty country performance, I’m minded of how I think about VC strategy, and what it means for what they’re doing.

I rate investments by two criteria: Is it a Big Wind, and is it a Capable Team.  There is a third as well, but it’s irrelevant to this discussion.

A Big Wind is a market opportunity where lots of money will change hands.  And Capable Team is a team that can seize the opportunity and ride it out despite all twists and turns (and there are always twists and turns).

So we invest, and things don’t go well.  Like Greece, the company’s income is less than its expenses.  Over time.  Repeatedly.  Without apparent hope of things turning around on their own.

I’ve developed a 2×2 grid for asking what to do with a company based on evolving circumstances.  It looks like this:

Presentation1.pptx
Download this file

If the wind is big and the team is capable, you don’t need to do anything: you let ’em rip.

If the wind is big but the team isn’t capable, you topgrade the team until they become capable.

If the wind is small but the team is capable, you pivot.  You find a new wind, or a better take on the existing wind.

If the wind is small and the team is incapable, you let it go.  You sell it, you shut it down.  You dispose of it.

The Euro community is foundering.  I don’t know enough to know if the wind is small or the team incapable, or both, but someone should make this analysis if they want the community to survive.

What the community is doing instead, and what a lot of VC firms do instead, is probably the worst of all possible worlds: put the incapable team on a starvation budget so they can’t possibly take advantage of a big wind, but at least they won’t go under right away.

It’s neither fish nor flesh nor fowl.  And it won’t serve the Euro community any better than the same strategy serves us in trying to get our startups to thrive.

Your thoughts?

I got an Arduino for Fathers’ Day from my son, and an Arduino Cookbook from my wife.

The Maker Movement just went personal for me.

In case you don’t know what the Maker Movement is, it’s a bottom-up movement of hardware tinkerers, largely hobbyists today, which I believe will revolutionize manufacturing and basically end the Industrial Revolution (or cause a new one, depending on how you look at it).

In case you don’t know what an Arduino is, it’s a popular open-source hardware module with a programmable controller and some I/O junk that sells for ~$20 and is pretty easy to program.

(That’s pretty easy for me to see; I haven’t programmed it yet.  Catch up with me a few weeks and see how easy I think it is.)

First application?  My son suggested I make a gizmo to automatically power-cycle my cable modem.  Not a bad idea, although my ISP says you should disconnect the coax cable as part of the process, which means some way to interrupt the coax.

First step in any project of this source: scour what my son calls “the InterTubes” for prior art.  I’ll start on that this week.

Very cool stuff, at least for me.