Which is better: waterfall development or spiral development?

When asked a question such as this, the interviewer is clearly looking for more than a one word answer.  Pointing out accurate and relevant pros and cons of each method is far more important than your final opinion. An answer such as the following might be suitable.

The choice of SDLC methodology for a project largely depends on: (1) the type of project, and (2) the environment or organizational culture within the project takes place.  With that said, a Spiral method is superior for the vast majority of projects today, especially those which include the development of customer facing products.

When the Spiral method was first introduced, it was intended for use on very large and complex problem spaces.  It incorporated characteristics of the Waterfall method (Requirement Elicitation, Analysis, Design, Code, Test), but did so in an iterative way.  So first, it should be noted that the two are not exactly mutually exclusive.  However, while each iteration of the Spiral method may have originally been intended to span 6 months to even a year or more (an entire little waterfall of its own) with the advent of Agile methods in recent years, the iterations of the Spiral method have become compressed to a much smaller time frame; sometimes as short as 2 weeks, but often just a month or two.

Any iterative method can provide a number of benefits over its Waterfall counterpart:

This is where the discussion of most analysts typically ends.  However, there are also some downsides to a Spiral method. 

It can become easy for an agile team following a Spiral method to fall into the habit of doing sloppy upfront analysis, since a miss of a requirement or feature can be fixed in a future iteration.  While the Spiral method does mitigate some of the effects of missing important items, this laziness can also eliminate an important advantage of a Spiral method; capturing additional ROI from the early release of features.

Finally, and most importantly, any iterative method means that portions of a product/application are being designed and coded before the entire scope of the design is known. This can lead to a large amount of UI and code refactoring; refactoring being the term used to describe the redesign and recoding of portions of the existing system in order to accommodate new features and functionality.  At the very least, this can mean significant re-work that might have been avoided. However, some early system design and architectural decisions can sometime constrain what is achievable down the road.  So, at its worst, this could mean an eventual redesign and re-write of an entire product or system.

This doesn’t mean that a Spiral method shouldn’t be used.  In most cases, its advantages far outweigh its disadvantages.  But project team members should be aware of the risks such that they can establish processes and habits early on that will help mitigate these risks.

Chris Adams
LinkedIn Profile

posted @ Saturday, April 7, 2012 3:08 PM by Chris Adams