Background
In the August 2014 edition of the IET's E&T Magazine, Tim Fellows wrote an article titled How to avoid getting sucked into the black hole of software development (link). The article seems to blame the bulk of software related problems on the contracts, but I think Mr Fellows misses the point completely.
I'd like to challenge some of the points made…
The Article
Three quotes struck me most:
- They decide to get the software written by a programmer … who has only a little experience.
- Software development can easily become a black hole like this, with serious consequences.
- Now, I know software is a bit of a dark art to most people.
Put together, these three comments point to serious project management failings, rather than contractual issues!
A Dart Art
I accept that software is a bit of a dark art to most people but the dark art stems from the intangibility of software – you either have a piece of working code, or you don't. Likewise, many programmers seem to enjoy maintaining the mystique that software has, and there is a view in some quarters that writing clever code marks you out as a good programmer.
Nothing should be further from the truth. A good programmer writes code that is easy to understand, and equally importantly, easy to maintain.
Experience
We were all novices once, and we all have to learn – but the project manager who uses an inexperienced programmer with little (or no) support, supervision or mentoring only has themself to blame.
A Black Hole
It is a standing joke that software spends 90% of its time 90% complete – partly this links to the previous observation that you either have a piece of working code, or you don't. But far too often, there is ambiguity as to the requirements, and this leads to a never ending series of tweaks and changes. This is especially the case when "people who want to dive right in"
Mr Fellows rightly suggests that defining the work in some detail at the start … focuses the mind and can avoid a lot of unforeseen problems and lost time later.
Quite right.
Software Engineering
Quite simply, software engineering should be viewed in the same way as every other engineering discipline…
One would not ask an electronics supplier to make me a PCB or a mechanical housing supplier to make me a metal box without issuing a signed-off specification, yet this seems to be acceptable in the software world.
Maintaining Standards
I find it puzzling that, in the era of ISO 9000, so many companies are so informal with their software development processes. There is no reason why ISO 9000 should not apply to software – and indeed the BSI TickIT scheme (assessed to ISO 90003) should be considered by any company developing in-house software.
And of course, I would recommend the use of MISRA guidelines too!
Even with the advent of Agile (and similar "processes") there is no excuse for not capturing the project requirements, and performing appropriate design and test reviews – and for managing the development cycle.
Failure to manage a project willl result in the project failing – you cannot simply blame the dark arts of the inexperienced programmer for your project falling into a black hole.
