Friday, March 11, 2011

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.

2 comments:

  1. As an engineering consultant, one of the rules I live by is:
    "If a prospective customer will not WRITE DOWN what they want, you will NEVER make them happy. RUN, DO NOT WALK, to the nearest exit!"

    ReplyDelete
  2. Steve,
    Couldn't agree with you more!

    ReplyDelete