Iterative software development Vs Water Fall Software development [duplicate]

Question

This question already has answers here:

Is the Waterfall software development methodology still viable? (6 answers)

Closed 3 years ago.

Why is Iterative software development better than Waterfall software development? In the Iterative method it take more time because of iterations and start with minimum small planning which is not good because with minimum planning which can easily lead us to wrong path.

Instead if we use waterfall method first we will make all our plans and predict about different difficulties and after that we code only if our plans and design pass.

If our plan is not good or have some bugs we can fix it early.

Answer 1

Why Iterative software development is better than Waterfall software development?

Because with the iterative method, one starts with minimal planning and then validates that planning against what the customer needs at an early stage. This actually helps ensure we are not led down the wrong path. As a result, less time is spent trying to completely plan before starting as well as saving time reworking late in the project when those plans are found to be wrong.

Instead if we use the waterfall method, we spend a considerable amount of time planning for what the customer thinks they need, which will be different to what they really need. Only then do we start to code, which almost immediately reveals holes in that "full planning exercise" and starts to highlight false assumptions in the plans. Those then must be reworked before development can proceed.

Eventually, we "complete" the coding and pass it over to test. At that stage further mistakes, both in the plans and code are found, resulting in a now very costly reworking phase.

Finally we present it to the customer. "That isn't what I wanted" then springs from their lips. More plans are made. More coding ensues. More testing is performed. Eventually, we arrive at something the customer can live with (it's still not what they really wanted, but costs are rocketing). So we ship. Next time, the customer goes elsewhere.

The big problem with waterfall is that it was never intended to be used in real life. It was designed as an example of exactly how not to run a project. Sadly, a great many companies missed the joke, took it seriously and tried to use it. The results speak for themselves.

Answer 2

If you know exactly what you want and how to do it then waterfall works great !

Iterative approaches on the other hand will make this unknown factor an integral part of your process. You thus plan well to the point of uncertainty where you will stop and gather more information before correcting and continuing towards the adjusted goal.

Apply an iterative approach to a problem that is familiar and well defined you might be wasting valuable time asking questions for which you already have the answer. Using waterfall on a problem that is vaguely defined and you will waste a lot of time in conjectures and planning for possibilities that may never occur, you also risk missing important things that are not easily foreseeable in the present.

Neither is bad or good, they serve different needs.

Answer 3

There is a saying about failing to plan is planning to fail. Call your methodology whatever you want and use it happily as long as your methodology forces you to balance requirement gathering, planning & designing, and implementation such that your end result is viewed as success, it is supportable and extendable, and along the way you didn't run into a lot of re-work and setbacks because the requirements and/or expectations changed.

The business continues to evolve as projects churn. A lot of things can happen to push your perfect project off of what you thought was a solid foundation on top of solid requirements. Also, there are time-to-market considerations in a lot of cases.