The Waterfall paradox
There's a lot of confusion regarding that grandaddy of software development process models, the so-called Waterfall. So many things are meant by the name that it has long ago ceased to be useful as a name, but people still argue as if the name "Waterfall" pointed to something definite. I think that's the source of much apparent disagreement among people who discuss software development processes.One common point of agreement is that "Waterfall" applies best to projects where little discovery needs to be done and the problem domain is well known, in contrast to Agile processes which supposedly work best in innovative or high-uncertainty projects where a lot of learning is to be expected as the project unfolds.
If I know the problem domain, then indeed I can usually divide solving a problem in step A, then step B, then step C. Cooking feels like that; although I've taken it up recently enough that there's a lot of discovery going on, there's always a certain order things are supposed to be done. If I follow that, and get the timing right, and the proportions, I end up with an edible meal. Well, sometimes.
This is one of the main characteristics that people seem to have in mind when they talk about Waterfall - a (mostly) fixed sequence of steps, that have to be done in the right order.
A different, distinct idea that people seem to have in mind when discussing Waterfall is the precise list of steps that are to be performed in any software development project. The original Waterfall article had six - they went "Requirements, Analysis, Design, Coding, Testing, Deployment". Sometimes one or the other is omitted in a description of the process, and there are many variants, such as ones in which "Testing" is distributed throughout the project (smart move). The main point is that in any project the steps to perform are those, in that order.
There's no similarly generalized model for cooking that holds for all recipes I've done so far (and I dont know that many). Sometimes it's "gather ingredients, mix, bake, serve". Other times you do these in a different order, omit one, do one twice or more. There are many other types of steps, too. (There's even some rigorous research into what works and what doesn't in cooking, a lot of it counter-intuitive. Cooking, like programming, is far from trivial.)
What bugs me about that "standard" Waterfall, the one that goes requirements - design - implementation, is where did these phases come from ? Why are they the "standard" way of doing things ?
It strikes me - that's the paradox - that the Waterfall phases are a wonderful way to learn about a problem. As a generalized problem solving framework they work beautifully.
First we define what the problem is, expose our assumptions about it, formulate concrete and achievable goals, etc. Right there in the "requirements" phase we learn a lot about the problem - if we do it right, sometimes we no longer have a problem by the time that phase is over. Then we move into "design", which is where we have the opportunity to think about what The System is that we are proposing to modify, explore possible unintended consequences of our proposed actions to solve the problem, and so on. Again an opportunity to re(de)fine our understanding of the situation. And then, in "implementation" we get to test our models against reality; that's where we learn whether the system responds to our interventions in the expected ways.
If we truly know the problem domain, chances are that there is a specific sequence of steps that apply. If you're designing a compiler, you can famously farm out the work to as many subteams as your compiler is expected to have passes. Only if we're tackling an unknown problem does it make sense to adopt the generic Waterfall phases, and then as a strategy for learning.
The generic techniques defined by the "classic" Waterfall phases work best for discovery, but the Waterfall process is said to work best in projects where there's little discovery to be done. Ironic, or what ?
No comments:
No trackbacks:
Trackback link:
Please enable javascript to generate a trackback url