Causes of software development woes

Respondents point the finger at ambiguous requirements

‘Agile development’ can mean different things to different people. To some it’s about easing up on traditional rigour, and even legitimising a quick-and-dirty approach to getting stuff out of the door. To others it’s about implementing a different kind of rigour, in order to bust project backlogs in a more robust manner, and generally keep up with constantly changing business demands.

The one thing few dispute in all this is the ‘constantly changing demands’ bit. If you work in and around software development, we’d be surprised if you weren’t experiencing pressure to produce new releases and roll-out change-requests faster than ever before. Indeed, this came through strongly in a recent survey that we ran towards the end of last year, as did the difficulty of dealing with these dynamics.

Wrapped up in all this is the behaviour of fickle users and stakeholders, who often guess or assume too much up front, then change their minds later when you deliver what they asked for. Not everyone on the business side of the house falls into this category, but if you’re an experienced developer, you will undoubtedly have come across them.

But are these kinds of people becoming more common? It sometimes seems so, but the truth is that even the most thoughtful and responsible of users and stakeholders are finding it increasingly difficult to pin down their needs. This is especially the case in relation to customer-facing applications deployed in a fast-moving market context. But with lots more activity ‘going digital’ across the business as a whole, volatility is becoming the norm rather than the exception.

Advocates of Agile will be quick to point out that this is a pretty good reason for taking a more iterative and forgiving approach – one in which you don’t necessarily need to have everything spec’d out before you cut a line of code. Fine in theory, but unless you are both organised and efficient in one very fundamental area – requirements engineering – it’s hard if not impossible to get sustainable results. Put simply, whether you are using Agile or not, if you are in an environment where requirements are either iteratively defined or constantly evolving, you need mechanisms in place to handle that.

Various forms of requirements-registers and change logs have a role to play here, and there are lots to choose from, including open source options. Visual tools connected into requirements databases and models can then make both change management and communication of requirements and dependencies a lot easier and more effective.

The research tells us, though, that the facilities actually in place now are often piecemeal and/or clunky. As a result, despite the use of alternative methodologies, requirements-ambiguity comes top of the list of factors cited in the study as likely to undermine software quality and efficacy.

If any of this sounds familiar, we have written it all up into a short report that you might find useful, along with a few tips and recommendations. And if you find some of the stuff we are pointing out a bit obvious, we make no apologies for that. While many indicate they know what they should be doing, they clearly aren’t acting on that insight. It’s usually not their fault, it’s more likely to be down to difficulty finding time to stand back and look at all of the dependencies and root causes of the issues.

You can download your copy of the report here.

Article originally published on The Register

Dale Vile

Click here for more posts from this author

Dale is a co-founder of Freeform Dynamics, and today runs the company. As part of this, he oversees the organisation’s industry coverage and research agenda, which tracks technology trends and developments, along with IT-related buying behaviour among mainstream enterprises, SMBs and public sector organisations.