The trouble with software application development is that it is complex. Equally, the beauty of software application development is that it is so complex that its inherent power allows us to create wonderful tools, fabulous programs and powerful embedded controls that run our world for us more efficiently and more effectively – or at least, that’s the idea for the most part right?
The upshot of this complexity is that software application development is not simple to do. Logically then, a number of methodologies have grown and developed over the last half century or so to provide programmers with a process template of sorts around which to base the creation, debugging and ultimately the deployment of their code.
This is of course good news for the most part – but like any methodology (or any theology for that matter) there are believers and non-believers. Not to draw too obvious a parallel, but just as there are Christians, Muslims and Jews there are proponents of Agile, Waterfall, Object-Oriented, Rapid, Scrum, Test-Driven and Rational Unified software application development.
But do we need all these different “belief” systems to govern our application development? Shouldn’t we have narrowed the field down to a handful (or less) by now? The answer is probably always going to be no.
Just as there are different types of structured and unstructured data to deal with, programmers will also face challenging differences based on fundamental factors such as whether they are handling complex event processing tasks, especially mission-critical needs or perhaps difficulties thrown up by working with high-throughput High Performance Computing (HPC) systems.
But it’s not just data types that necessitate more than one software application development methodology; there is a human factor to consider here too. As “projects” go per se, it has been said that managing a software project is one of the hardest assignment and work control tasks that there is.
Any project (from baking cakes to creating applications) can go offline if it is undertaken within an unrealistic timeframe, without clearly defined scope from the start and without the best (and most appropriate) resources being applied to the project. Without these factors, Quality Assurance quite literally goes out the window.
Of course this is merely scratching the surface of this subject and there is much more to discuss. Which elements of the total development process rely most on a methodology backbone for example? Is it requirements gathering, is it modeling, is it planning for parallel concurrency to optimise processing power, is it unit testing, is it debugging, is it change management, is it deployment controls – or it is all of the above factors in equal measure?
The answer, very probably, is that it depends on the project and it depends on the team and the customer – and let’s not forget that they are always right, right?