Most people only know one way to run a project; they use a structure that in software development is called a "waterfall model." In a waterfall model, each stage of the project is finished in order, and the results enable the next stage, until you are finished.
For instance, in writing a term paper for school, you might choose a topic, gather some references about the topic, read them while taking notes or making notecards, produce an outline for your intended paper, write a first draft, and then produce a final paper. I think this is the basic process we were all taught in school, and sometimes teachers would even make you turn in intermediate steps just to make sure you were using the process.
An "iterative" model is a different way of doing things, and I think for some types of projects it is superior. In an iterative model, rather than finishing an entire stage before moving onto the next, you divide your project into iterations. At the finish of each iteration, you will have done some of all of the appropriate kinds of work, and ideally you will have some kind of product.
If you applied an iterative model to writing a term paper, your first iteration might result in a very rudimentary draft. You would have gathered only a few sources and skimmed them, produced a very sketchy outline, and put together the bare bones of the paper. The goal should be to end up with a crappy paper at the end of this first iteration. From having done the work so far, you should now know what kind of sources you need and want, and have a good idea where the paper is going. The next cycle will incorporate more sources and be much more complete, and will result in the next draft. You can continue this process of refinement indefinitely (or until the paper is due).
I'm only sketching this out in a very basic way, but there are a few obvious advantages of using an iterative model. First, as soon as you've finished the first iteration, you are always ready to turn in something. Even that horrible first draft can probably get you some grade. In software development, this makes even more sense - even a very "sketchy" program that runs allows people to see visible progress.
Second, you learn a lot during each iteration. When your users or clients see the sketchy program, they will be filled with ideas about what it should do, or you may learn that it wasn't what they wanted after all. Even writing an extremely rough draft of a paper often gives you a very good idea of how it should proceed.
Third, an iterative model prevents the major drawback of a waterfall model - that you may never finish a stage to your satisfaction. If you have to have the whole paper planned out before you begin, you might not get there. If you can't hammer out a complete set of requirements for your software project, you could lose weeks or months or even years that you could have been making progress on other fronts.
Ed taught a computer science class last semester, and many of his students turned in a final project that didn't run. I can't help but think some of them would have been helped by using an iterative model (as well as starting earlier and all of the other usual student tricks). It's better to turn in the 2nd generation code that runs than to turn in the niftier 3rd generation code that doesn't. Using an iterative model lets you hedge your bets this way - at nearly every stage you've produced something of value.
Subscribe to:
Post Comments (Atom)
2 comments:
It seems that the iterative approach would be particularly useful when putting something together to meet someone else's needs since you can find out more quickly that what you're doing isn't what they want.
This may work better for a software project than a "term paper" type project, imo, because the latter sort of project may be...for lack of a better phrase...sensitive to initial conditions in that your first, sketchy gathering of sources for writing the paper may commit you too early to a particular approach. And if you aren't getting feedback from another party, you may not be sufficiently jolted to seek out a broader range of information that would improve the work.
I guess this could also happen with a software project if you were working on it in a vacuum; I just suspect that doesn't happen very often.
And we all know people who stay in the early "lit review" stage of the thesis or dissertation way too long as a sort of procrastination. "The best dissertation is the completed dissertation" etc.
Genial post and this enter helped me alot in my college assignement. Gratefulness you as your information.
Post a Comment