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.

  • 1
    There is no good Methodology (note the big M). Use what fits your case best. – Robzor Sep 15 '17 at 12:51
  • 1
    Iterative software development solves the problem of spending x months or years to write an application, only to have the customer say "I know this is what I said I wanted, but it's not what I actually wanted." By developing frequent prototypes and confirming them with the customer, you are actually being led down the right path. – Robert Harvey Sep 15 '17 at 13:51
  • The choice isn't so binary as you make out. Even in the waterfall days there was the concept of delivery phases to spread the risk. – Robbie Dee Sep 15 '17 at 14:03
  • 1
    as @David says, waterfall is the very extreme anti-iterative example, which basically nobody does, btw, b/c it doesn't really work: just one mistake/change in specs and you're iterating. Waterfall was conceived as an illogical strawman, to show how logical and necessary iteration actually is, and to argue for short formally recognized iterations instead of long and ad-hoc iterations. – Erik Eidt Sep 15 '17 at 16:12
  • 1
    @Eric Eidt Waterfall is like a rare animal: everyone talks about it, but few have seen it. – Frank Hileman Sep 15 '17 at 16:59

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.

  • 1
    I would be interested in your comment about waterfall never intending to be used. I have never seen it used, but in the 80s, I did read about its use in government projects. – Frank Hileman Sep 15 '17 at 17:00

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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.