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]

About John Clark

My name is John Clark and I previously ran a software house called Reynard Thomson, from which this blog originally grew. In the meantime, we launched a video-based user testing service (Kupima) which didn't really take off, and I have since moved into a new field specialising on software-based research & development consultancy. I'm active on LinkedIn, and would love to connect to anyone who has an interest in software prototyping or R&D: http://uk.linkedin.com/in/jtclarkuk/
This entry was posted in General Business and tagged , , , , . Bookmark the permalink.

One Response to Who’s gonna do it?

  1. John Hyde says:

    Hi John, Came here from Joel :)

    Th big thing with software is that you can demolish bad or wrong stuff at no cost and without anyone seeing.

    This is what’s behind the rush to get going before anyone knows what to do: you can build a load of crap and hope it could be useful. And demolish the unwanted stuff free and silently.

    Compare with civil engineering where there is the cost of building the wrong thing then an extra cost and embarrassment of knocking it down.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>