Software Development Methodologies Choose Your Weapon
In the beginning there was a blank screen and a flashing cursor…
In the more established branches of engineering the nature of a problem are usually so well defined that the solution eventually writes itself. Ok, this may be a little bit of an over-simplification, but let us remember that where there is now a bridge, there once was a very metrically definable span of space or a “gap” between “this” and “that” side. Oh, and let’s not forget a whole bunch of immutable physical laws silently “assisting” the process of design.
When it comes to the development of software, sadly all solid physical parameters and immutable physical laws can be replaced with an abstract soup of hazy requirements and floating-point horizons. When we add to this the fact that in most cases budgets are set before the design is complete, then estimating the cost of a software project turns from being a science into the darkest of dark arts!
Delivering a project on time and on a budget is what most clients are interested in, but these may not always be the hallmarks of success.
The choice of software development methodology has a large impact on the cost of a software project, but also its ability to meet client requirements. Currently, the industry is trending towards a concept known as Agile Software Development (Scrum, XP, Kaban). This method focuses on delivering functionality as quickly as is possible, and through successive iterations of delivered functionality, it encourages the natural evolution of both requirements and their solutions. This method is ideal when it comes to situations where the requirements are not understood or agreed upon. With each passing iteration, we can contain some of the complexity and ambiguity, continually inspecting and adapting it to the realities of the requirements, technology and people combining to create the project.
A more predictive software development methodology is the Waterfall method.
It does as it says, with each stage of the development process, from requirements to design to implementation flowing on in distinct stages, from one to the next.
It is a more formal approach that works best when the customer knows exactly what they want and nothing changes other than bug fixes. It gets a lot of discredit because the vast majority of customers don’t know what they want, so Agile processes are far more effective at finding out just what customers want – and giving it to them. Hopefully, however, if the budget is fixed and the client’s understanding of the requirements remains abstract, any ambiguity can be offset by the development team’s wealth of past experience ( ie. Creativ Digital ;). This is a big “if”, but oftentimes there is no getting around it.
At the core of any success or failure of any software development project are the requirements! Both the client and the development team must do whatever can be done to condense the abstract soup in some sort of hearty stew or be brave enough to walk on air for part of the journey at least. Then and only then and only with a mild degree of certainty can we ensure that we aren’t building a metaphorical bridge to anywhere.
We’ll leave an analysis of the requirements phase for the next blog entry!
What are your thoughts on the best method leave a comment below…