Who’s gonna do it?

Creating great software isn’t easy.  There are loads of hurdles to overcome, and the risk of failure is real.  As I’ve written on many occasions, the best way to succeed is to minimise the risk of failure.  Sounds a bit obvious, doesn’t it?  You’d think so, wouldn’t you?

The problem is that too few people really put in enough effort up-front, which results in significantly higher risks further down the line.  Take, for example, the developer who dives into code before really understanding the requirements.  Perhaps those requirements aren’t immediately obvious.  Maybe there’s disagreement over what needs to be done.  Nevertheless, our intrepid developer wants to “make a start“.  Bad move.

Just like building a house, we need to have some baseline guidelines about what we’re going to do.  A builder won’t start work before he knows what kind of a house he has to build.  A four storey mansion requires a totally different approach to planning compared to a bungalow.  Yet, in software, we’re frequently at the beck and call of clueless management who pressurise developers into starting work without even draft requirements.

You’d think that in this day and age this would be the exception, but you’d be wrong.  I was recently involved in the development phase of a large and complex financial data collection system, whose delivery date was decided before anyone had any concept of the scope or what would be involved.  Worse, the necessarily unrealistic schedule depended upon having workable specs available in good time.  Guess what?  The development was almost complete before the merest hint of requirements documentation materialised.  And it was, basically useless when it did arrive, being as it was incomplete, full of errors and false assumptions.  Remember, kids, bad requirements can be as damaging as no requirements at all…

Despite this, we’d had to press on because the management – or should I say lack of management – had clearly no interest in letting its responsibility to manage the project get in the way of those juicy meetings.  Mmmmm… donuts!  So, not only had we useless requirements delivered way too late, we had absentee management of the very worst kind.

Ultimately, today’s article isn’t really meant to be a gripe.  After all, anyone who has been in this game for any length of time will have similar tales to tell.  What I did want to stress was that we, as the hopefully ‘enlightened’ techies, invariably have no choice but to take on the responsibility of pushing through requirements and kicking back against incompetent management.

If we don’t do it, we can’t really expect anyone else to do it.  Sure, it’s nice when it happens as it ought to, but don’t count on it…

[If you don’t already use one, it’s a good time to think about subscribing to this blog using our RSS feed and a suitable reader]

Advertisement