Be afraid, be very afraid

Be afraid, be very afraid

For Halloween this year I’ll be blogging a real horror story.  And when I say “real”, I mean real – everything you are about to read is the truth.  Not some Spielberg made up scary stuff.  Knowing that it’s real makes it just a bit scarier.  I’ve obfuscated some details to protect the identity of both the innocent and the guilty.

It all started some months ago, I was getting off a train in a European capital city and stepping into a thick swirling fog.  It was close to midnight. As I crossed the station platform I heard an owl hoot and fly away.  Climbing into a taxi, off in the distance, I could hear a wolf’s lonely howl – or could it be a werewolf? A shiver ran down my spine as I knew that I would be rising early in the morning to attend a post mortem. (Cue that creepy music from “The Exorcist”).

Well, not a real “dead body” post mortem, but I was asked to sit in on a review of a project; a project which was quite definitely dead.  Racked with delays, cost overruns, and lots of blame the project did not have a happy life.   I had been involved in the project from close to its outset, and even early on I could see that it was destined for trouble.  Needless to say, the corpse was not a pretty sight, and this meeting was not going to be a fun one.

The project had two major elements.  But the project teams working on the different elements were not coordinated.  They did not work together at all – in fact, they rarely communicated.  They started off by writing a specification of how the two sides would interface.  The specification was incomplete.  It contained errors, and was out of date by the time it was published.  As the project progressed, no one ever went back to update it – of course, this is inexcusable after the invention of the wiki.  But that wasn’t all that bad, since few people read the spec.  And fewer still even expected it would be complete or accurate.

Upper management decided not to co-locate these engineering organizations.  While both engineering groups had some contributors in far flung corners of the world, the bulk of one group was in a city in the U.S. and the locus of the other was in Europe.  There were many hours of time zone changes and cultural differences between the two.  The two groups did not even start on the project at the same time, one started a full 8 months after the other.

After many staff years of effort on the part of both groups – literally, a multi-million dollar/euro investment by the parent company – the momentous day came where the two parts of the system were brought together to form the whole.  The upper management of the project was shocked – shocked I tell you – that the whole thing did not come together and work the first time.  Shocked that there would be months more development and verification effort before the product could be released.

Here’s where the delays and blame started to pile up. Both sides accused the other of gross failures. Functionality was thrown overboard, as there were features that simply could not be implemented without redesigning major parts of the system.  The delays piled up.  Promised delivery dates came and went.  The marketeers saw their precious market window closing on them.  Everyone wanted someone to blame.  Smart folks were moving onto other projects.

A Horror story, no doubt.  You may be wondering how a competent engineering organization could execute so poorly. Surely your own organization would never do anything like this.  But there is one small detail I left out.

Preparing Recommendations

One group was designing software and the other was designing hardware.

Yes, lots of systems are still designed this way.  And I hear you saying “Well, that’s just software”.  Sure, software is more malleable (at least in theory).  It’s layered, so you only need to worry about the layer that touches hardware, right?  If you prove that A works with B, and B works with C, no need to verify that A, B and C all work and play well together, right?  And, my favorite “That’s the software guy’s problem”.  As a hardware developer, you were charged with developing the hardware – and you did it.  If software team can’t get their job done, well, that’s not your issue.  I’m guessing those shocked upper management types would beg to differ.

In my next blog post I’ll describe why you might want to worry about this, if you’re not already.  There is functionality which is starting to break the traditional boundaries between hardware and software. I’ll describe it, and what you can do about it.

More Blog Posts