Friday, March 11, 2011

To the Cloud

The next big software war to be fought is in the cloud. I have been following Google Apps since its inception as an offshoot of gmail. Google’s ever improving suite of online software has evolved into Google Docs and for businesses, Google Apps. It is an economical choice for a small business to provide protected email, shared calendar, messaging, software applications and shared access to documents with NO I.T. responsibility.

Now there is a new kid in town, or soon to be. Microsoft is about to debut Office 365. It will compete directly with Google Apps for business and provide a hosted productivity and collaboration environment for businesses. Small businesses who typically cannot afford an I.T. staff or who do not want to maintain their servers will now have a choice.

Google and Microsoft are providing an integrated suite of common office applications PLUS a collaboration platform PLUS messaging. When offered at an affordable price it becomes very appealing. Especially when it does not involve those dreaded server updates and reboots. Let some one else worry about that.

So let’s see how this develops, there are many questions. Does our internet infrastructure provide the kind of responsive we have become accustomed to with our desktop/notebooks and local area networks? How many businesses are going to adopt Cloud computing and store important documentation somewhere out there? How safe, private is this data?

Many questions, the story is now unfolding.

A sad yet preventable story of software failure

I read an article today reporting that Nokia had announced that it was abandoning its development of its own Smartphone platforms and APIs. By itself, that’s not so sad. It’s smart to know when to cut your losses, right? The reason this story makes me sad, is that it was entirely preventable.
According to reports from insider Mark Wilcox, “there was no proper requirement spec for this new framework.” Aggghhhh! This makes me crazy every time I see it, and I see it a lot.
Companies think they can save time, or they don’t want to be “locked in” or say, “We’ll just tell the developers what to build.” In 20+ years of personal experience, I’ve never seen this work well. In the very best cases, tons of time is actually wasted by long meetings, miscommunications, and do-overs. Usually the end result is not really what the project sponsor wanted, but they settle. In the very worst cases, like this one, companies spend 2000+ man-years (yes, you read that right) developing something no one wants! In this case, they had two competing teams (I’ll have to address that in another post – just too much to say on that one!) and according to Wilcox "both teams had built the wrong thing.” Both teams! (This post may be my personal record in use of exclamation points.)
Another comment he makes is that “the engineers were incompetent. Now by that I don't mean that they're incompetent engineers – far from it. They were incompetent at designing APIs for 3rd party developers (a very specialist engineering skill) and they were incompetent at designing UIs (which most engineers are, myself included). Unfortunately they were doing both.” These could have been very bright engineers, but as Clint Eastwood said in one of my favorite Dirty Harry Movies, “A man’s got to know his limitations.” This also happens frequently and is an error made both by engineers (ego, desire to learn, fearing for their job security) and management (don’t want to hire specialists, over estimating their engineers). Again, in the best cases I’ve seen, the engineers can muddle thru and get something passable. On the other hand, it can be a train wreck as in this case.
The aspect that makes me the most upset about this story is the effect on all those engineers. They worked hard, I’m sure long hours at times, to develop basically, nothing. We engineers develop software and products because we take pride in our work and want to build things that people love to use and these engineers spent years not doing that. I can’t even imagine how unfulfilling that was.