Just spare 2 minutes to think that building a software is like constructing a home.
1. You can construct a home without a blueprint.. It will definitely be built…. but if some one else purchases the house tomorrow will he know the wiring, strengths and weakness of the house.
2. Will the new comer know the security advantages and restrictions of the house or should it remain an assumption.
3. Tomorrow if somebody wants to add a new room in a new floor wouldn’t it help to have a blue print of the house or does he have to study the house or just break the house and start allover again because he does not know the wiring details etc
4. Houses if properly planned can be built to even be earth quake resistant as they are now present in earth quake prone regions after a previous earth quake.
5. Watch the news and serials where day in and day out buildings are collapsing or roof is falling or there are water leakages, all due to poor construction work.
In short Waterfall model is one extreme and Agile is another extreme. We need to strive to achieve the perfect results of a waterfall model while using the pace and speed of an agile model. Try to think of the two models as a weighing balance where the product is stable only if the weights are equal.
Conclusion:
1.Just because a region has frequent earth quakes, it is wrong to infer that we do not require a blue print for constructing the house and changing the blueprint as and when new additions are made. On similar terms just because the requirements are changing it is wrong to conclude that changing requirements should not be recorded in a formal approach.
2. We need to aim at Earth Quake resistant houses that have good blue prints and with good explanation of all its whereabouts such as security features, positives and negatives that are not assumed but are explicitly stated. Similarly we need software that are robust and have all requirements captured and that have well documented artifacts that don’t make room for assumptions.