The not so positive perceptions which have been created around the waterfall model have probably to do more with the lack of understanding among the software professionals than anything else. It is interesting to note that every model and methodology which has been proposed has always been defined against the backdrop of waterfall model - either as its derivative (like V-model, incremental, iterative, etc.) or as an alternative (like agile, etc.).
It is also interesting to note that the description of these 'new' and supposedly better models and methodologies has been around how they have managed to address the shortcomings of the waterfall model. The above discussion seems to have reached a new height with the advent of the agile methodology in the last decade (the agile manifesto came into being in 2001).
Agile has been proposed as an alternative to the supposedly 'heavy' waterfall model. Lot of discussion has been about how agile will eventually replace waterfall. In all this discussion the key message seems to have got lost somewhere.
Would one be happy if the meal offered on the flight is cold and stale? or worse the pilot informs that the fuel tank has been leaking and the plane is going to crash? The answer to both is no, however the second no is much more serious case.
Drawing analogy to the software domain would one be happy if while working on a document the software freezes and one has to reboot the machine and looses few lines of data? or worse while making an online payment one's credit card details are stolen? Again the answer is no with the second no being more serious than the first one.
Waterfall should be looked at as a concept that promotes efficiency. The essence of waterfall is zero rework. Once a phase is complete it never gets revisited and that means no rework, which means higher efficiency. Waterfall concept assumes that the most efficient way to do software is to do it right first time.
Living up to pure waterfall approach is extremely difficult as human mind hasn't evolved to the level where the intended system behavior can be understood perfectly at the start (as this involves two subjective factors - humans talking/writing/reading in a language like English which is not based on scientific principles) or the exact on-field behavior of a system at the architecture and design stage predicted with absolute certainty. And then there are natural reasons like new technology, new regulations, new concepts, new thoughts etc. which might trigger changes to the original system requirements and design.
Use of a pure waterfall approach was never the case even in the past. Even in the so called waterfall projects design changes to take care of issues and defects observed in end-stage testing is not an unheard phenomenon. The preparation of a list of "known issues" that usually gets bundled as part of the software package for release is a very common practice. The firefighting projects pass through at release time is also a common occurrence.
These examples demonstrate that a pure waterfall was never and can never be followed. No one would, however, disagree with improving the way software gets developed and the constant attempts to reduce the cycles of rework and minimize the list of "known issues".
Taking this one step ahead, use of iterative, incremental, spiral and agile can be seen as essentially doing waterfall in short and repetitive cycles with overlapping and parallel phases and activities, as the case may be. Especially in respect of agile one must consider the answers to some key questions:
These assumptions are no doubt very real but may end up becoming an excuse for complacency or not pushing the envelop. At the same time, the need to work better and better every time would mean certain discipline is exercised to ensure revisits and consequent reworks are minimized in line with the waterfall concept. What is probably the need of the hour is to have a hybrid approach that combines the best of various models varying the flavors as the customers want it.
The concept behind waterfall is going to remain relevant and important forever. The waterfall model is the original one and must be adapted in whichever way it might be, with a new name if that helps improve software development (agile or whatever).
It is also interesting to note that the description of these 'new' and supposedly better models and methodologies has been around how they have managed to address the shortcomings of the waterfall model. The above discussion seems to have reached a new height with the advent of the agile methodology in the last decade (the agile manifesto came into being in 2001).
Agile has been proposed as an alternative to the supposedly 'heavy' waterfall model. Lot of discussion has been about how agile will eventually replace waterfall. In all this discussion the key message seems to have got lost somewhere.
- The first and the most fundamental question is "why is software required in the business context"? Is it for the creative satisfaction of the software developer or serving a business need of the software user? It can be safely assumed that is is always the latter that any CEO will agree to and for very obvious reasons. This basic understanding clearly implies that a software project is meant to deliver business value to its customers.
- The second question is "can we ever develop perfect software"? Ideally one would want that to happen but based on pragmatic considerations this is like being able to count till infinity. It follows from here that some bugs will remain and more importantly the customers will be willing to tolerate it subject to considerations of applicable laws and regulations, safety, reliability, availability, functionality and value for dollar spent to procure and use it.
Would one be happy if the meal offered on the flight is cold and stale? or worse the pilot informs that the fuel tank has been leaking and the plane is going to crash? The answer to both is no, however the second no is much more serious case.
Drawing analogy to the software domain would one be happy if while working on a document the software freezes and one has to reboot the machine and looses few lines of data? or worse while making an online payment one's credit card details are stolen? Again the answer is no with the second no being more serious than the first one.
Waterfall should be looked at as a concept that promotes efficiency. The essence of waterfall is zero rework. Once a phase is complete it never gets revisited and that means no rework, which means higher efficiency. Waterfall concept assumes that the most efficient way to do software is to do it right first time.
Living up to pure waterfall approach is extremely difficult as human mind hasn't evolved to the level where the intended system behavior can be understood perfectly at the start (as this involves two subjective factors - humans talking/writing/reading in a language like English which is not based on scientific principles) or the exact on-field behavior of a system at the architecture and design stage predicted with absolute certainty. And then there are natural reasons like new technology, new regulations, new concepts, new thoughts etc. which might trigger changes to the original system requirements and design.
Use of a pure waterfall approach was never the case even in the past. Even in the so called waterfall projects design changes to take care of issues and defects observed in end-stage testing is not an unheard phenomenon. The preparation of a list of "known issues" that usually gets bundled as part of the software package for release is a very common practice. The firefighting projects pass through at release time is also a common occurrence.
These examples demonstrate that a pure waterfall was never and can never be followed. No one would, however, disagree with improving the way software gets developed and the constant attempts to reduce the cycles of rework and minimize the list of "known issues".
Taking this one step ahead, use of iterative, incremental, spiral and agile can be seen as essentially doing waterfall in short and repetitive cycles with overlapping and parallel phases and activities, as the case may be. Especially in respect of agile one must consider the answers to some key questions:
- Is agile an original concept? not really. It is not fundamentally different from the decades old concepts of incremental, iterative, spiral development
- Is agile valid from a scientific or conceptual standpoint? not really. The agile manifesto tends to view software development work as an art and not science. Even conceptually it seems to encourage rework over solid understanding of the customer's need and the proposed solution right at the start (evolution in understanding can't be considered as an excuse for not applying scientific methods at the start to gain as much understanding as possible in a cost-effective and pragmatic manner)
- Is agile the proverbial silver bullet? not really. Every model and methodology has its pros and cons. However, the ultimate acid test for any model is the business value it helps to create for the end customers. One may use use different model at different stages of the project as is the most appropriate.
- Is agile 'the model' the software industry was waiting for? not really. It is one of the many models that have come up in the last and newer ones that will emerge in the future
These assumptions are no doubt very real but may end up becoming an excuse for complacency or not pushing the envelop. At the same time, the need to work better and better every time would mean certain discipline is exercised to ensure revisits and consequent reworks are minimized in line with the waterfall concept. What is probably the need of the hour is to have a hybrid approach that combines the best of various models varying the flavors as the customers want it.
The concept behind waterfall is going to remain relevant and important forever. The waterfall model is the original one and must be adapted in whichever way it might be, with a new name if that helps improve software development (agile or whatever).
No comments:
Post a Comment