Java™ Application Development on Linux - Dator

266Chapter 11Balancing Acts: An Imaginary ScenarioThis list, when done in that order, has been referred to as the classic“waterfall” model—each step is done in its entirety (or largely so) beforeproceeding on to the next step.Or at least that’s the ideal which programmers have often pursued.The problem is that the process involves people, and people, especiallythose responsible for the requirements, a) are sometimes unimaginative and 2)keep changing their minds. They start out with some requirements, based onwhat they think they’re going to need. But they just aren’t imaginative enoughto think of how terrible their system will be for the average user. They also keepchanging their minds as to what they want. 1The “iterative” approach has been tried as a way to address this problem.Rather than wait for all requirements to be spelled out perfectly, with the iterativeapproach you jump right in with what you do know, build that, but expectchanges to come. The sooner you get a working product or prototype into thehands of the users, the sooner you’ll get feedback on what works, what doesn’t,and what is really wanted (“what works” is used here not in the testing sense,but in the usability sense).Note, however, that in the iterative approach, one still gathers requirements,develops designs for the code and the tests, develops them, tests (andfixes) the code, and releases it. It’s just that one does that on a much smallerand more rapid basis. You get something runnable sooner, and continue tomodify it.Some people will complain that this makes for more expensive rework,but we (and others) would disagree. You are refining the process. Your reworksare less expensive than if you went to the work of building the entire systemonly to have some key requirement(s) change—there can be a lot more“wasteage” there.Be aware, however, that the iterative approach is not just “whipping thehorses to run faster.” It is not just the waterfall model run at high speed. Rather,it is using the early iterations of the product as a sort of a “living” requirementsspecification, one that you can show to people and that they can try out, in realworldscenarios, and on which they can give feedback. Don’t expect to be ableto compile complete requirements, but don’t give up on talking to your end1. Did you notice that we tried to hint at that ever-enjoyable mid-project shifting of requirementsas we went from a) to 2), changing our numbering scheme midway? Minimal humor,admittedly, but if you’ve lived it, you understand.